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About This Issue 


improvements in computer performance 
can be realized by judicious use of a cache 
memory. The survey by Alan Jay Smith 
discusses the various design features of 
cache memories. It includes presentations 
of several algorithms — such as cache-fetch, 
placement and replacement, and up- 
dating — that affect the efficiency with 
which a cache memory can be used. 
Throughout the paper, the author draws on 
the results of simulations in order to com- 
pare techniques. Implementations of the 


cache memory in the Amdahl 470V/6 and 
470V/7, the IBM 3033 and 370/168, and the 
DEC VAX 11/780 are used in these com- 
parisons. Smith’s paper is a significant con- 
tribution in that it brings together the var- 
ious avenues of research pertaining to cache 
memory designs, and introduces the Sur- 
vey’s readers to simulation techniques for 
analyzing the use of cache memory algo- 
rithms. 

Adele J. Goldberg 

Editor-in-Chief 
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Interactive Editing Systems: Part I 

NORMAN MEYROWITZ AND ANDRIES VAN DAM 

Department of Computer Science, Box 1910, Brown University, Providence, Rhode Island 02912 

Matty daily tasks, whether done with conventional tools or with computers, can be viewed 
as editing tasks: tasks in which the state of some target entity is changed by the user. 

This article, Part I of a two-part series, examines computer-based interactive editing 
systems, which allow users to change the state of targets such as manuscripts and 
programs. 

This paper is a tutorial that defines terms and introduces issues for the novice, and 
provides a reference for the more knowledgeable reader. The aim is to provide a 
comprehensive and systematic view of the features of typical systems, highlighting 
substantive similarities and differences. User and system views of the editing process are 
provided, a historical perspective is presented, and the functional capabilities of editors 
are discussed, with emphasis on user-level rather than implementation-level 
considerations. 

Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools and 
Techniques — user interfaces', D.2.3 [Software Engineering]: Coding— prettyprinters; 
program editors; H.4.1 [Information Systems Applications]: Office Automation — 
equipment ; word processing; 1.7.0 [Text Processing]: General; 1.7.1 [Text Processing]: 
Text Editing — languages; spelling; 1.7.2 [Text Processing]: Document Preparation — 
format and notation; languages; photocomposition; I.7.m [Text Processing]: 
Miscellaneous 

General Terms: Design, Human Factors, Languages 

Additional Key Words and Phrases: Syntax-directed editors, structure editors 


INTRODUCTION 

The interactive editor 1 has become an es- 
sential component of any computing envi- 
ronment. It uses the power of the computer 
for the creation, addition, deletion, and 
modification of text material such as pro- 
gram statements, manuscript text, and nu- 
meric data. The editor allows text to be 
modified and corrected many orders of 
magnitude faster and more easily than 
would manual correction. 

Though editors have always been 
deemed important tools in computing sys- 

* "Editor" throughout refers to an interactive editing 
program, not to an author/user correcting a document. 


terns, they have only recently become a 
fashionable topic of research, as they be- 
come key components in the office of the 
future. No longer are editors thought of as 
tools only for programmers, or for secre- 
taries transcribing from marked-up hard 
copy generated by authors. It is now in- 
creasingly realized that the editor should 
be considered the primary interface to the 
computer for all types of knowledge work- 
ers, as they compose, organize, study, and 
manipulate computer-based information. 
Unlike the literature in areas such as pro- 
gramming languages or operating systems 
(with rich collections of written materials, 
from basic definitions and tutorials to com- 
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ex formalisms, analyses, and implemen- 
,tion strategies), the Uterature in the field 
; editing consists primarily of functional 
ascriptions of particular editors. Little 
ork has been done to standardize termi- 
ology or to create a framework for com- 
aring,' contrasting, and analyzing editing 

/stems. ...... 

This two-part series is designed as a start- 
ng point for developing such a framework. 
)ur intended audience is composed of two 
listinct groups: those with only limited ex- 
perience with an interactive editor and 
hose with a broader background in the 
ield. Part I is tutorial in nature and is 
neant for those with only superficial expe- 
ience in using an editor to create program 
>r document text. It is a reasonably com- 
prehensive introduction to text editing. As 
such, it is not meant to be read in its en- 
tirety by the editor designer, but rather to 
be used as a reference. It is here that we 
present bur definitions and overview of the 
field, making explicit what has previously 
been largely implicit or passed on as oral 
tradition.’' We look at document editing 
from a user and system standpoint, at some 
of the major historical developments, and 
at the functional capabilities of editors. 

Part II presents technical details of spe- 
cific editors, using the terminology and 
concepts laid out in Part I. The reference 
list for both parts is included at the end of 

PartIL . , ..... 

Several topics directly related to inter- 
active editing will not be covered here; 
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instead, we supply references to surveys in 
those fields. In particular, text-formatting 
techniques are left to Furuta et al. 
[Furu82], implementation of edit ors is cov- 
ered by Rice and van Dam [Riue71] and 
Finseth [Fins80], editor evalumion is sur- 
veyed by Embley and Nagy [Embl 81], and 
graphics editors are described in Newman 
and Sproull [Newm79] and Foley and van 
Dam [Fole82], 

1. GENERAL OVERVIEW 

1.1 The Editing Process 

An interactive editor 1 is a computer pro- 
gram that allows a user to create and revise 
a target document. We use the term 
“document” to include targets such as com- 
puter programs, text, equations, tables, dia- 
grams, line art, and halftone or color pho- 
tographs— anything that one might find on 
a printed page. In this paper we restrict our 
discussion to text editors (in which the 
primary elements being manipulated are 
character strings of the target text) used tor 
manuscript and program production, and 
to structure editors (in which the primary 
elements being manipulated are portions of 
some generic structure such as a tree). 

The document-editing process is an in- 
teractive user-computer dialogue (1) to se- 
lect what part of the target is to be viewed 
and manipulated, (2) to determine how to 
format this view on-line and then to display 
it, (3) to specify and execute operations that 
modify the target document, and (4) to 
update the view appropriately. 

Selection of the part of the document to 
be viewed and edited involves first travel- 
ing through the document to locate the 
area of interest with operations such as next 
screenful, bottom, and find pattern. Next, 
having specified where the area of interest 
is, the selection of what is to be viewed and 
manipulated there is controlled by filtering. 
Filtering extracts the relevant subset of the 
target document at the point of interest, 
such as the next screen’s worth of text or 
the next statement. Formatting then deter- 


2 in this paper, italic type is used to introduce concepts 
and terms. Sans serif type is used to set off editor 
commands. Boldface type is used for emphasis. 
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mines how the result of the filtering will be 
seen as a visible representation, the view, 
on a display screen or hard-copy devlce - 
Only in the actual editing phase is the 
target document created or altered per a 
set of operations, commonly includmg m- 
sert, delete, replace, move, and copy. 1 1 
editing functions are often specmlued t 
operate on elements meaningful to the type 
of editor, such as single characters, wort . , 
lines, sentences and paragraphs for manu- 
script-oriented editors, and keywords and 
source language statements for progran 

oriented editors. . * . 

In a simple scenario, then, the user might 
travel to the end of a document. A screen s 
worth of text would be filtered, this subset 
would be formatted, and the view would be 
displayed on an output device. The user 
then, for example, could delete the first 
three words of this view. 

1.2 The Editor: A User Viewpoint 

The user of an interactive editor is pre- 
sented with a conceptual model of the sys- 
tem, which is the designer’s abstract bam - 
work on which the editor and the world 
in which it operates are based, and with 
user interface, the collection of tools and 
techniques with which the user communi- 
cates with the editor. 

The conceptual model, in essence, pr - 
vides an easily understood abstraction of 
the target document and its elements, and 
1 set of guidelines with which to anticipate 
the effects of operations on these elemen^ 
Conceptual models range from those that 
are hardly visible to the user and not very 
coherive or thorough, to those that are well 
articulated and provide a consistent and 
complete framework both for «sing and for 
implementing the system. ^ °thers, the 
conceptual model is incomplete, it is insut 
ficient to describe more than a very cursory 
notion of the system Some of the early fine 
editors simulated the world of t he Ke y 
nunch allowing operations upon numbered 
sequences of 80 -character card image lines, 
either within a single line or upon an inte- 
gral number of lines. Some more modern 
fereen editors define a world m which a 

document is represented as a quarter^ 

of text lines, unbounded both downwar 


and to the right. The user sees through a 
cutout only a rectangular subset of this 
plane at any time on a multiline display 
screen, but can move the cutout both left 
and right and up and down to see other 
portions of a document. Operations manip- 
ulate portions of this quarter-plane without 

regard to line boundaries. 

The user interface contains the input at* 
vices the output devices, and the interac- 
tion language of the system. Examples of 
each of these are discussed in the following 
subsections. Along with the user interface 
the user is often given documentation that 
may include a description of the conceptual 

model a high-level description of the sys- 
tem architecture in user-level terminology, 
a user's guide detailing the syntax and se- 
mantics of the interaction language, anda 
tutorial that provides operational defin 
tions and demonstrates typical situations 
with examples. 

Each individual forms a personal user 
model of an editing system, partly ^ ‘ 

olated from information provided in the 
recorded documentation or passed on by 
“experts” and partly based on i-epeateduse 
of the system. The user model may differ 
from the conceptual model in severe ways 
First, it can be thought of as a subset of the 
conceptual model. For example, a user ex- 
perienced in document preparation may 
have no notion of the language-specihc 
commands for correct program indentation, 
similarly, a programmer may have no n 
tion about the features provided for on- me 
table manipulation. Second when the nser 

consistently uses combinatio^ of P r *' 
fives to perform common operations m 
ways not originally encompassed by the 
conceptual model, the user model can be 
thought of as an extension ofthe conC ^ tU ^ 
model. Third, the user model can be 
thought of as an operationally equivalent 
but logically different form of the concep- 
tual model. For example, rather than con- 
sidering his or her actions to be moving a 
cutout over various parts of a document as 
described above, the user may consider the 
cutout as stationary and the document as 
scrollable horizontally and vertically p 

th The u^r model is a personalized, high- 
level understanding of the conceptual 
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model provided, of the manipulable entities 
and their interrelationships, of the set of 
operations allowed on the entities, and of 
the interaction language used to invoke 
these operations. The user model is not 
simply descriptive but prescriptive as well: 
to perform editing tasks, the user employs 
the user interface based on his or her user 
model. 

1.2.1 User Interface 

1.2.1. 1 Input Devices. Input devices are 
used for three main purposes: (1) to enter 
elements, (2) to enter commands, and (3) to 
designate editable elements. These devices, 
as used with editors, can be divided into 
three categories: text devices, button de- 
vices, and locator devices [GSPC79, 
Fole82]. 

Text or string devices are typically type- 
writerlike keyboards on which a user 
presses and releases a key to send to the 
CPU or to an I/O controller a unique code 
for each key. Essentially all current com- 
puter keyboards are of the QWERTY va- 
riety. This variation of keyboard, named 
for the first six letters in the second row of 
the keyboard, was invented by Christopher 
Latham Sholes in the 18C0s. The strange 
key layout was done for purely mechanical 
reasons — letters most commonly used to- 
gether were placed as far apart as possible 
so that mechanical typewriter keys would 
not clash. As surveyed in Mont82, several 
experimental text input devices have been 
constructed. The Dvorak Simplified Key- 
board rearranges the keys to reduce fatigue 
and increase typing speed; despite experi- 
mental evidence showing its superiority, it 
has not caught on strongly. The Montgom- 
ery “wipe-activated” keyboard requires the 
user not to press keys, but rather to “wipe” 
a stylus across the keyboard surface. Let- 
ters comprising common digrams arid tri- 
grams, such as TH and ING, are placed next 
to each other on the keyboard; the user 
simply wipes the wand from left to right 
across the letters, rather than typing two or 
three separate keystrokes. NLS’s keyset 
[Enge68] consists of a pad of five long keys, 
similar in shape to white piano keys, ami 
provides a method for entering small text 
additions or corrections. Each key corre- 
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sponds to a position in a 5-bit binary word 
called a “chord"; by depressing the proper 
combination, the user can represent 2 5 - 1 
= 31 numbers or ASCII codes (binary 
“00000” is not counted, as this means no 
keys are being pressed). 

An alternative to direct keyboard input 
is optical character recognition (OCR). 
Typically a standard electric typewriter, 
(inexpensively) equipped with an OCR type 
element, is used for typing the text on nor- 
mal paper. This paper is then fed through 
an optical character reader, an electrome- 
chanical device that scans the page and 
translates each character into the proper 
digital representation for that computer 
system. This technique allows the contin- 
ued use of preexisting facilities: the type- 
writers become off-line “links” to the com- 
puter facilities. Although many OCR sys- 
tems also allow rudimentary editing of the 
raw text stream via character- and line- 
delete control characters inserted in the 
text, this cannot compete with the conven- 
ience and essentially instant editing facility 
of on-line input. While OCR is often seen 
as an inexpensive way to begin “compu- 
terization,” it is contrary to the spirit of on- 
line authoring, in which the author is able 
to express his or her thoughts and experi- 
ment with a composition from its inception. 

Button or choice devices generate an in- 
terrupt or set a system flag, usually causing 
invocation of an associated application pro- 
gram action. They typically are grouped as 
a set of special function keys on the alpha- 
numeric keyboard or on the display itself. 
Alternatively, buttons are often simulated 
in software by having the user choose text 
strings or symbols displayed on a screen. 

Locator devices are x-y analog-to-digital 
transducers that position a cursor symbol 
on the screen by continually sampling the 
analog values produced by the user’s move- 
ment of the device. They include joysticks, 
trackballs, touch screen panels, data tab- 
lets, and mice. The latter two are the most 
common locator devices for editing appli- 
cations. The data tablet is a flat, rectangu- 
lar, electromagnetically sensitive panel. 
Either a ballpoint-pen-like stylus or a puck, 
a small (approximately 3 inch square X 1 
inch high) device that fits in the palm of 
the hand, is moved over the tablet surface. 


The tablet returns to a system program the 
coordinates of the point on the data tablet 
on which the puck or stylus is currently 
located. The program can then map these 
data tablet coordinates to screen coordi- 
nates and move the cursor to the corre- 
sponding screen position. The mouse is an- 
other hand-held device about the same size 
as the puck. As it is moved on a flat surface, 

' the motion of the mouse causes relative 
changes in x and y to be sampled by a 
system program. These mouse coordinates 
are again mapped to screen coordinates to 
move a cursor on the screen. 

A locator device coupled with a button 
device allows the user to specify either a 
particular point on the screen at which text 
should be inserted or deleted, or the start 
and endpoints of a string of characters to 
be operated upon. In fact, the mouse and 
puck usually have built-in buttons for the 
user to signal a selection. When the cursor 
has been positioned over an element, the 
user presses a button to indicate the selec- 
tion; the system correlates the cursor posi- 
tion with the element that it covers and 
performs the appropriate action. 

Text devices with arrow (cursor) keys are 
often used to simulate locator devices. 
These keys each show a pictured arrow, 
pointing up, down, left, or right, respec- 
tively. Pressing an arrow key typically gen- 
erates an appropriate character sequence, 
which the program then translates to up- 
date the cursor position in the direction of 
the arrow on the key pressed. Up, down, 
left, and right keys must be used sequen- 
tially to position the cursor a character at 
a time, aided typically by continuous move- 
ment in “repeat mode," which the device 
enters if a key is held down for more than, 
say, a second. 

Still in the research stage, voice input 
devices, which translate spoken words — 
both literal text and commands— to their 
textual equivalents, may prove to be the 
text devices of the future. While currently 
restricted to a small vocabulary (typically 
fewer than 1000 words), voice recognizers 
may soon be commercially viable for com- 
mand recognition. 

1.2.1.2 Output Devices. Formerly limited 
in range, output devices for editing are di- 
versifying. The output device serves to let 


the user view the elements being edited and 
the results of the editing operations. The 
first-generation output devices were the 
(now largely obsolete) teletypewriters and 
other character-printing terminals, which 
generated output on paper. Next, “glass 
teletypes” based on cathode ray tube 
(CRT) technology used the CRT screen 
essentially to simulate a hard-copy tele- 
typewriter, although a few operations, such 
as backspace, were performed more ele- 
gantly. Today’s advanced CRT terminals 
use hardware assistance for such features 
as moving the cursor, inserting and deleting 
characters and lines, and scrolling lines and 
pages. The new generation of professional 
work stations, based on personal computers 
with high-resolution raster displays, sup- 
ports multiple proportionally spaced char- 
acter fonts to produce realistic facsimiles of 
hard-copy documents. Thus the user can 
see the document portrayed essentially as 
it would look when printed on paper. 

While many editors, especially tradi- 
tional ones, have interfaces that allow 
them to run on both CRT and hard-copy 
terminals, we concentrate on the more so- 
phisticated capabilities that can readily be 
implemented only on CRT terminals with 
user-manipulable cursors. Much of the 
discussion does, however, apply to both 
hard-copy and CRT output devices. 

1.2.1. 3 Interaction Language. The inter- 
action language of a text editor can be 
divided into three parts: the semantic com- 
ponent, the syntactic component, and the 
lexical component [Fole82]. The semantic 
component of the language specifies func- 
tionality: what operations are valid for each 
element, what information is needed for the 
manipulation of each element, what the 
results of the operations are, and what er- 
rors may occur. The semantic component 
defines meanings of the specified opera- 
tions, not particular data structures or dia- 
logues to implement those operations. 

The syntactic component specifies the 
input and output rules by which tokens, as 
the atomic elements, are put together to 
form sentences in the grammar of the lan- 
guage. In terms of editor input, the set of 
tokens might include character strings, 
commands, and screen positions. In terms 
of output, the set of tokens might include 
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character strings, lines, and formatted 
paragraphs. The syntax must be easy for 
the user to learn and remember, and must 
follow naturally from the conceptual model 
of the system. The syntax of interaction 
languages is generally one of three sorts: 
prefix, postfix, or infix. A prefix (verb/ 
noun) command specifies the operation de- 
sired, followed by the elcment(s) which that 
operation will affect. A postfix (noun/verb) 
command specifies just the opposite: the 
element to be operated upon is specified 
first, followed by the operation. An infix 
(noun/verb/noun) command is a cross be- 
tween the two former types: the operation 
is surrounded by its operands. Typically 
infix only is needed when more than one 
operand exists. Many languages are basi- 
cally postfix, but rely on infix in the cases 
where more than one operand is needed. In 
a cross-product interface, the user can 
match a noun from a list of nouns with a 
verb from a list of verbs to form the appro- 
priate command. In other types of inter- 
faces, the verb/noun distinction is not al- 
ways clear-cut; a single editor command, 
such as delete-word, can be composed of 
both a verb and noun. Here the user speci- 
fies the command delete, and the element 
is particularized to the nearest unit of the 
corresponding type word. 

The lexical component specifies the way 
in which lexemes, information from the in- 
put devices or for the output devices, are 
combined to form the tokens used by the 
syntactic component. Thus typing the lex- 
emes D, -, W, followed by a carriage return, 
would result in the delete-word token. 

The interaction language is generally one 
of several common types, based on the 
manner of specifying lexemes. The typing- 
ox text command-oriented interface is the 
oldest of the major editor interfaces. Here, 
the user communicates with the editor by 
typing text strings both for command 
names and operands. These strings are sent 
to the editor and are usually echoed on the 
output device. 

Typed specification often requires the 
user to remember the exact form of all 
commands, or at least of their abbrevia- 
tions. (Some systems will prompt the user 
with valid choices if an ambiguous com- 
mand abbreviation is typed.) If the inter- 


action syntax is complex, the user must 
continually refer to a manual or an on-line 
“help” command for a description of less 
frequently used commands. Additionally, 
typing is time consuming, especially for the 
beginner. The function-key interface ad- 
dresses these deficiencies. Here each com- 
mand has associated with it a marked key 
on the user’s keyboard. For example, the 
insert character command might have as- 
sociated with it a key marked 1C. Forgetting 
the commands is unlikely, since they are 
literally at the user’s fingertips. For the 
common functions, usually only a single key 
need be pressed. Function-key syntax is 
typically coupled with cursor-key move- 
ment for specifying operands, thereby elim- 
inating much typing. Advocates cite 
“muscle memory” of key location as a prime 
advantage of function key interfaces. 

For less frequently invoked commands or 
options in a function-key editor, an optional 
textual syntax may be used. More com- 
monly, special keys “shift” the standard 
function key interpretations, just as the 
shift key on a typewriter shifts the standard 
interpretation of a key from being lower- 
case to being uppercase. As an alternative 
to shifting function keys, the alphanumeric 
keyboard is often overloaded to simulate 
function keys. The user again uses special 
shift keys — the most common being the 
control 3 key (CTRL) depressed simulta- 
neously with normal keys to generate new 
characters that are interpreted like function 
keys. Generally, functions are assigned to 
alphanumeric keys in two ways: topologi- 
cally and mnemonically. In topological lay- 
out, functionally similar keys are grouped 
in close proximity; for example, in Brown’s 
66 [Reis81], the control key coupled with 
the Q, W, E, or R keys correspond to delete 
word, delete to end of line, delete to blank 
line, and delete paragraph, respectively, 
while the keys directly below, A, S, D, F, 
coupled with the control key, correspond to 
insert word, insert to end of line, insert to 
blank line, and insert paragraph. Another 
topological layout is seen in Wordstar 
[Micr81], in which the cursor commands, 
up, down, left, and right, are bound to the 

3 In examples, the control key will be abbreviated 
CTRL- and the escape key ESC. 
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i CTRL-E, CTRL-X, CTRL-A, and CTRL-F 
keys to make use of their relative directions 
on the keyboard. Mnemonic layout binds 
commands to keys whose letters or symbols 
invoke some type of mental image or con- 
nection. For instance, in the EMACS 
[Stal80] default key bindings, CTRL-B, 
CTRL-E, CTRL-F, CTRL-R, and CTRL-K 
stand for Backward character, End of line, 
Forward character, Reverse search, and 
Kill line, respectively. 

Typing-oriented systems require famil- 
iarity with the system and language, as well 
as some expertise in typing. Function-key- 
oriented systems often have either too few 
keys, thus requiring keyboard-overloading 
by binding single keys to several interpre- 
tations and necessitating multiple key- 
stroke commands, or have too many unique 
keys, resulting in an unwieldy keyboard. In 
either case, even more agility is demanded 
of the user than by a standard keyboard. 
The menu-oriented user interface is an at- 
tempt to address these problems. A menu 
is a multiple-choice set of text strings or 
icons (graphical symbols which represent 
objects or operations) from which the user 
can select items to perform actions 
[GoiA.79]. The editor prompts the user 
with a menu of only those actions that may 
be taken at the current state of the system. 
The user knows that if a command appears 
in the menu, it can be selected, and the 
typical “you can’t do that operation in tliis 
(x) mode” error messages that occur with 
other types of interfaces are eliminated. 

One problem with a menu-oriented sys- 
tem can arise when there are many possible 
actions and multiple choices required to 
complete an action. Since the display area 
for the menu is usually rather limited, the 
user might be presented with several con- 
secutive menus in a hierarchy before the 
appropriate command and its options ap- 
pear. Since this can be annoying and det- 
rimental to the efficiency of a seasoned 
user, some menu-oriented systems allow 
the user to turn off menu control, leaving a 
language- or function-key-oriented editor 
as a base. Others have the most-used func- 
tions on a main command menu and have 
secondary menus to handle the less fre- 
quently used functions. Still others display 
the menu only when the user specifically 


asks for it. For instance, in more modern 
editors based on a Smalltalk-80 '-like inter- 
face [Tesl81, GolA 82] (see Figure 1), pop- 
up menus, in response to the user s button 
push, instantly appear on some part of the 
screen near the cursor (perhaps temporarily 
overlapping some existing information) to 
give the user the full choice of applicable 
commands. The user selects the appropri- 
ate command with a mouse; the system 
executes the command and the menu dis- 
appears instantly. Interfaces like this, in 
which prompting and menu information are 
given to the user at little added cost and 
little degradation in response time, are be- 
coming increasingly popular. 

While the semantic component of the 
language is similar from system to system 
(at least for simple operations), the lexical 
and syntactic specification of commands 
vary widely. For example, to delete the 
word “bazinga” in an editor using typed 
commands from a keyboard without cursor 
keys, one might search for an occurrence of 
the pattern bazinga and then type delete/ 
bazinga; in another, using typed commands 
with cursor keys, one might type dw after 
driving a cursor to point at any character 
in the word bazinga; in a function-key 
driven system, one might press the del word 
key (or keys) after pointing at bazinga; and 
in a menu-oriented system, one might point 
to and then select the b in bazinga, adjust 
the selection to the entire word by pushing 
the adjust button, and then select the de- 
lete icon from the displayed menu. 

The interaction language can be viewed 
as a layered architecture: similar semantics 
can be reflected in a variety of syntaxes, 
while similar syntaxes can be reflected in a 
variety of lexical styles. For example, given 
semantic routines that perform insertion 
and deletion in an unbounded stream of 
characters, designers could provide a prefix 
or postfix syntax for specifying insert or 
delete commands. Similarly, given either 
the prefix or postfix syntax, designers could 
provide typing-oriented, function-key-ori- 
ented, or menu-oriented lexical input styles. 
This layering invites device independence, 


3 Smalltalk-80 is a registered trademark of Xerox Cor- 
poration. 


Computing Surveys, Vol. 14, No. 3, September 1982 


{28 


N. Meyrowitz and A. van Dam 



Figure 1. A Smalltalk-80 pop-up menu, 
mouse, points to the cut item in the pop-u 
window. When the proper mouse button i 
the menu, no longer needed, disappears. 

im-e differing lexical forms can be mapped 
mo the same syntax. The layering also 
Hows syntax independence, since differing 
yntactical styles can be mapped into the 
ame semantic operations. 

.3 The Editor: A System Viewpoint 

■Editors in general follow an architecture 
imilar to that in Figure 2, regardless of the 
■articular computers on which they are 
mplemented and the features they offer. 

The command language processor ad- 
epts input from the user’s input devices, 
exically analyzes and tokenizes the input 
tream, syntactically analyzes the accumu- 
ated stream of tokens, and, upon finding a 
■gal composition of tokens, invokes the 
ippropriate semantic routines. 

At the syntactic level, the command lan- 
uage processor, like a programming Ian- 
uage processor, may generate an interme- 
iate representation of the desired editing 
perations instead of explicitly invoking the 
emantic routines. This intermediate rep- 
osentation is decoded by an interpreter 
bat invokes the proper semantic routines, 
rhis allows the use of multiple interaction 
yntaxes with a single set of semantic rou- 
ines that are driven from a common inter- 
nediate representation. 

The. semantic routines invoke traveling, 
diting, viewing, and display. While editing 
■perations are always specified explicitly by 
he user, and the display operations im- 
ilicitly' by the other three categories of 
■perations, traveling and viewing opera- 
ions may be either explicitly specified or 
mplicitly invoked by the editing opera- 
ions. In fact, the relationship between 


Here the arrow cursor, driven by the 
> menu temporarily overlapping the text 
pressed, the command is executed and 


these classes of operations may be consid- 
erably more complicated than the simple 
model of Section 1.1 (travel to determine 
where the selection should take place, fil- 
ter to select what is to be viewed and 
manipulated, format to determine how the 
view is to appear, then edit, and reformat) 
might suggest. In particular, there need not 
be a simple one-to-one relationship be- 
tween what is “in view,” that is, what is 
displayed on the screen currently, and what 
can be edited. To illustrate this, we take a 
closer look below at the . components of 
Figure 2 which are meant to be conceptual 
entities. 

In editing a document, the start of the 
area to be edited is determined by the cur- 
rent editing pointer maintained by the ed- 
iting component of the editor, the collection 
of modules dealing with editing tasks. The 
current editing pointer can be set or reset 
explicitly by the user with a traveling com- 
mand such as next paragraph and next 
screen, or implicitly by the system as a side 
effect of the previous editing operation, 
such as delete paragraph. (The traveling 
component of the editor actually performs 
the setting of the current editing and view- 
ing pointers, and thus the point at which 
the viewing and/or editing filtering begins.) 
When the user issues an editing command, 
the editing component invokes the editing 
filter. The editing filter filters the document 
to generate a new editing buffer based on 
the current editing pointer as well as the 
editing filter parameters. These parameters 
are specified both by the user and the sys- 
tem, and provide such information as the 
range of text that can be affected by the 
operation, for example, the “current line” 
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in a line editor or the “current screen" in a 
display editor. Filtering in both the case of 
editing and viewing may be defaulted to the 
selection of contiguous characters at the 
current point or may depend on more com- 
plex user specifications pertaining to the 
content and structure of the document to 
gather not necessarily contiguous portions 
of the document, as discussed in Section 
3.1. The semantic routines of the editing 
component then operate on the editing 
buffer, which is essentially a filtered subset 
of the document data structure. (Note that 
this explanation is at the conceptual level- 
in a given editor, filtering and editing may 
be interleaved, and no explicit editing 
buffer created.) 

Similarly, in viewing a document, the 
start of the area to be viewed is determined 
by the current viewing pointer maintained 
by the viewing component of the editor, the 
collection of modules responsible for deter- 
mining the next view. The current viewing 
pointer can be set or reset explicitly by the 
user with a traveling command or implicitly 
by the system as a side effect of the previous 
editing operation. When the display needs 
to be updated, the viewing component in- 
vokes the viewing filter. The viewing filter 
filters the document to generate a new 
viewing buffer based on the current viewing 
pointer as well as the viewing filter param- 
eters. These parameters, again, are speci- 
fied both by the user and the system, and 
provide such information as the number of 
characters needed to fill the display and 
how to select them from the document. The 
viewing buffer may contain the current 
line” or the null string (for “silent” feed- 
back) in line editors, while in screen editors 
it may contain a rectangular cutout of the 
quarter plane of text. This viewing buffer is 
then passed to the display component of 
the editor, which maps it to a window or 
viewport , a rectangular subset of the screen, 
to produce a display. 5 


a The term “viewport" is standard for “visible repre- 
sentation on the screen” in computer graphics termi- 
nology, while in editing terminology, the term 
“window” is used loosely to mean both the viewing 
buffer and the mapped representation of the viewing 
buffer on the screen. Unfortunately, the term 
"window” in graphics terminology is analogous to our 
“viewing buffer," lending more confusion to the defi- 


The editing and viewing buffers, while 
independent, can be related in many ways. 

In the simple case they are identical, as in 
the case of screen editors, in which the user 
edits the material directly in view on the 
screen, rather than specify material with 
typed commands (see Figure 3). 

The editing and viewing buffer can also 
he disjoint. For example, in the Berkeley 
UNIX 6 editor ex [JoySOa], a user might 
travel to line 75, and after viewing it, decide 
to change all occurrences of “ugly duckling 
to “swan” in lines 1 through 50 of the file 
by using the substitute command: 

1 ,50s/ugly duckling/swan/g 

As part of this editing command, there is 
implicit travel to the first line of the file, 
lines 1 through 50 are filtered from the 
document to become the editing buffer, and 
successive substitutions take place in the 
editing buffer without corresponding up- 
dates of the view. If the pattern is found, 
the current pointers are moved to the last 
line on which it was found, and that line 
becomes the default contents of both the 
editing and viewing buffers, while if the 
pattern is not found, line 75 remains as the 
default editing and viewing buffers. 

The editing and viewing buffers can be 
partially overlapping on a screen when 
the user specifies a search to the end-of- 
document starting at a character position 
in the middle of the screen. Here the editing 
filter creates an editing buffer that contains 
the document from the selected character 
to the end of the document, while the view- 
ing buffer contains the part of the docu- 
ment that is visible on the screen (only the 
last part of which will be in the editing 

buffer). . . , 

Finally, the editing and viewing bulters 
may be properly contained in one an- 
other. As an example of the editing buffer 
contained in a larger viewing buffer, the 
CPT word processing editor [SkyP 79J al- 


nitions. We have tried to limit the use of the term 
“window" to reduce confusion, but when we do, we 
use it in the editing sense of the “mapped representa- 
tion of the viewing buffer on the screen." We uBe the 
term “view” to mean a "display of a filtered subset of 
a document in a window." 

6 UNIX is a trademark of Bell Laboratories. 
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Figure 2. The editor: a system architecture. 


lows full 8V4 X 11-inch page views. The user 
must scroll a page to put a line to be edited 
at the typing bar, analogous to rolling the 
platen of a typewriter to align the desired 
line with the typing element. Here the ed- 
iting buffer corresponds to the one-line sub- 
set of the document which is in the middle 
of the viewing buffer. Conversely, a number 
of traditional editors, limited by low-speed, 
line-oriented output devices, provide a large 
editing buffer. The viewing buffer is a small 
initial subset of the editing buffer to allow 
quick regeneration of the view; the entire 
scope of the editing operation need not be 
in view. The FRESS editor [vAND71a, 
Prus 79] allows the user to select the num- 
ber of lines and the number of characters 
per line for the viewing buffer (the default 
being a single line the width of the display 
device for alphanumeric terminals) and also 
allows the user to select the size of the 
editing buffer (the default being 2000 char- 
acters); the viewing filter selects as many 
characters as necessary, starting at the be- 


ginning of the editing buffer, to provide the 
viewing buffer for the necessary display. 

Windows typically cover either the entire 
screen or a rectangular portion of it. Map- 
ping viewing buffers to windows that cover 
only part of the screen is especially useful 
for editors on modem, high-resolution ras- 
ter-graphics-based work stations, as they 
allow the user to examine and to interact 
with multiple views, for inter- and intrafile 
editing and “cutting and pasting." The no- 
tion of multiple viewing buffers and multi- 
ple windows showing differing portions of 
the same or multiple files at the same time 
on the screen is designed into such editors. 
Alternatively, on graphics-based work sta- 
tions with multiwindow display managers 
or window managers that allow the user to 
manipulate the placement of windows on a 
screen [LRG76, Teiw77, Lant79, Meyr81, 
Symb81, Tesl81], the user can run a one- 
viewing-buffer editor in each of the many 
windows. It is through the support of the 
display manager, not of the editor, that the 


Computing Surveys, Vol. 14, No. 3, September 1*)H‘> 


Interactive Editing Systems: Part I * 331 



rimirA a Elements of the editing component. The diagram above shows the relationship of the current 
Figure • . , . editine buffer and the viewing buffer. In this diagram, the file is 

HE £? 

exploded diagrfm since the viewing buffer coincides w.th the editing buffer in this example. 

pi, window, containing P“'™ ”f the “ "T "* S°” hr cion), to . 

same file or porttons of multiple files words ( ragged g j formatted/ 

edttg a fi“nl it typeset text wi/equations, tables, and fig- 

£1221*5 2sf£aSK£SSS£S 

Mfea ss srrf r*r 

mechanism » only now b.ginning to g.in > - »n i.»h« 

•■arsKKKSEr.^ — . = i«!jas, 2255 ; 


Computing Surveys. Vol. 14. No. 3. September 1982 















332 • N. Meyrowitz and A. van Dam 

version and, using the innate capabilities of 
the terminal, write only those characters 
needed to generate a correct display. Typ- 
ical algorithms for this intelligent screen 
update are described in Arno80, Bara81, 
Gosl 81, and Stal81. 

Device-independent output, like device- 
independent input, promotes interaction 
language portability. This decoupling of ed- 
iting and viewing operations from display 
functions for output is important for pur- 
poses of portability: it is unwieldy to have 
a different version of the editor for every 
particular output device. Many editors 
make use of a terminal control database 
[Joy 81]. Instead of having explicit termi- 
nal-control sequences in display routines, 
these editors simply call terminal-inde- 
pendent library routines, such as scroll 
down or read cursor position, that look up 
the appropriate control sequences for the 
host terminal. Consequently, adding a new 
terminal merely entails adding a database 
description of that terminal. 

In addition to the interrelated traveling, 
viewing, editing, and displaying compo- 
nents, special utility components, such as 
spelling checkers/correctors and word- 
count analyzers, may exist to provide a 
variety of services to aid the user in docu- 
ment production. 

The components “communicate” with a 
user document on two levels: in main mem- 
ory and in the disk file system. At the 
beginning of an editing session the editor 
first asks the file system to open the appro- 
priate file and then reads the entire file or 
files, or portions thereof, into main mem- 
ory. Loading an entire document into main 
memory may be infeasible. Yet if only a 
portion of the document were resident in 
main memory and if many user-specified 
operations entailed a disk-read by the edi- 
tor to load the affected portion, editing 
wduld be unacceptably slow. In many mod- 
em systems this problem is solved by map- 
ping the entire file into virtual memory and 
letting the operating system perform effi- 
cient demand paging. Alternatively, in sys- 
tems without virtual memory or with lim- 
ited virtual memory per user, editor paging 
routines are required. These read in one or 
more logical chunks of a document, called 
pages (although there is typically no cor- 

Computing Surveys, Vol. 14, No. 3, September 1982 


respondence between these pages and hard- 
copy document pages or virtual memory 
pages), into main memory, where they re- 
side until a user operation requires another 
piece of the document. In either case, doc- 
uments are often represented not as se- 
quential strings of characters, but in an 
editor data structure that allows addition, 
deletion, and modification with a minimum 
of I/O and character movement. When 
stored on disk, ihe file may be stored in 
terms of this data structure or in an editor- 
independent, general-purpose format (e.g., 
as character strings with embedded control 
characters such as linefeed and tab). 

1.3.1 Configurations 

Editors function in the three basic types of 
computing environments: timesharing, 
stand-alone, and distributed. Each type of 
environment imposes some constraints on 
the design of an editor. The timesharing 
editor must function swiftly within the con- 
text of the load on the computer’s proces- 
sor, primary memory, and secondary mem- 
ory. The editor on a stand-alone system 
must have access to the functions that the 
timesharing editor obtains from its host 
operating system; these may be provided in 
part by a small local operating system or 
may be built into the editor itself if the 
stand-alone system is dedicated to editing. 
The editor operating in a distributed re- 
source-sharing local network must, like a 
stand-alone editor, run independently on 
each user’s machine, and must, like a 
timesharing editor, contend for shared re- 
sources such as files. 

Some timesharing-based editing systems 
take advantage of local (terminal-based) 
hardware to perform editing tasks. These 
intelligent terminals have their own micro- 
processors and local buffer memories in 
which editing manipulations can be done, 
thus saving the time needed to read and 
write main computer memory, but adding 
tricky data structure synchronization prob- 
lems. Small actions are not controlled by 
the CPU of the host processor but are han- 
dled by the local terminal itself. In a system 
using an IBM 3270 series terminal, for ex- 
ample, the editor sends a full screen of 
material from the mainframe computer to 
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the terminal. The user is free to add and 
delete characters and lines; when the buffer 
has been edited, its updated contents are 
transmitted back to the mainframe. The 
advantage of this scheme, that the host 
need not be concerned with each minor 
change or keystroke, is also the major dis- 
advantage. With a nonin telligent terminal 
the CPU “sees” every character as it is 
typed in and can react immediately to per- 
form error checking, to prompt, to update 
the data structure and to record or 
“journal” the keystrokes for undoing edit- 
ing operations (see Section 3.4). With an 
intelligent terminal, the lack of constant 
CPU intervention often means that the 
functionality provided to the user is more 
limited. Also, local work on the intelligent 
terminal is lost in the event of a system 
crash. Conversely, systems that allow each 
character to interrupt the CPU may not 
use the full hardware editing capabihties of 
the terminal because the CPU needs to see 
every keystroke and provide character-by- 
character feedback. 

As the local-area network of largely self- 
sufficient work stations becomes the domi- 
nant architecture, we may expect that the 
problem of synchronizing intelligent termi- 
nals with timeshared hosts will disappear 
and that character-by-character feedback 
will become the norm. 

2. HISTORICAL DEVELOPMENT OF 

EDITORS 

The history of editing is one of many com- 
plementary development efforts proceeding 
in parallel. Editors are so numerous and 
their relationships so cloudy, that it is very 
difficult to provide an accurate chronology. 
Rather, we briefly overview some of the 
important concepts, citing familiar and rep- 
resentative examples. (For a survey of spe- 
cific editors through 1971, see vAND71b.) 

Noninteractive computerized editing be- 
gan with the manipulation of “unit record” 
punched cards. The basic unit of informa- 
tion was the 80-column line; the user made 
corrections on a line-by-line basis, retyping 
mistyped cards. Compared to toggling in 
bits at the system console, the card gave 
the programmer new freedom. One could 
store information in both human- and ma- 


chine-readable form, and one could “travel’ 
through this information, changing ius or- 
der, discovering and fixing errors, recogniz- 
ing color-coded groups of cards, or simply 
browsing through the deck. 

Punched card decks had many disadvan- 
tages, such as the “rearrangement” that 
resulted when a box was accidentally 
dropped. More seriously, editing a small 
part of a large document required feeding 
the entire document, often thousands ol 
cards, into the reader for every change. To 
correct small errors such as single-character 
errors or double-character transpositions, 
the user had to retype the offending char- 
acters and to replicate the other character.- 
with the duplication facilities of the key 
punch. Replacing a word with a word of a 
different size necessitated duplicating all 
characters prior to the word and retyping 
all the characters from the new word for 
ward. If the incorrect card was almost com 
pletely filled with characters, inserting i 
new word might result in overflow of tin 
contents, causing the insertion of one oi 
more new cards to handle the overflow 
Performing a global change required man 
ually finding every occurrence of the ol. 
pattern and again manually replacing l 
with the new pattern; if the new patten 
were larger than the old pattern, multipl 
overflows could easily occur. 

To address the problems of the punche. 
card in the still predominantly batch envi 
ronments of the 1960s, card or batch edi 
tors were created. Here the programmer 
initial deck of cards was stored as a card 
image tape or disk file. Each card was rei 
erenced by a unique sequence numbe 
Changes were made by creating an ed. 
deck composed of cards containing editin 
requests, and running the deck through th 
batch editor program. For example, the r. 
quest “in card 35, correctly spell the woi 
‘rate’ ” would be made by simply typing th 
desired sequence number 35 on one cai 
followed by a card containing the new coi 
tents of line 35, or more simply, by compo 
ing a card with a sequence number and i. 
editing command, as in 
35 CHANGE/RATA/RATE/ 

Batch editors removed the problems 
dropped cards and of retyping (in mai 
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cases), and, in some versions, provided new 
operations such as global replacement of a 
pattern. There were several disadvantages, 
however. Programmers needed to have a 
line-printer listing of the entire card deck 
before making any change. Also, some of 
the organizational characteristics offered 
by cards, such as the easy visual inspection 
of a properly sequenced, color-coded, and 
well-labeled card box, were lost. 

Systems like IBM’s MTST [IBMG7], 
which used a Selectric typewriter as an 
input device and small magnetic tapes and/ 
or cards as storage media, were the forerun- 
ners of today’s word-processing systems. 
Because these primitive interactive editors 
relied on sequential storage media such as 
magnetic tape or magnetic cards, the user 
could only step through card images lin- 
early, stopping at lines which needed cor- 
rection and retyping them. To go backward, 
the user had to “rewind” and then “fast- 
forward” the file to the desired place. In 
addition, the utility of these initial line ed- 
itors was limited by the typewriters, which 
supported the viewing of only one line at a 
time and had very slow printing speeds. 

With the advent of timesharing in the 
mid-1960s, interactive line editors were de- 
signed that allowed the user to create and 
modify disk files from terminals. These ed- 
itors attached either fixed or varying 
(“varying” meaning "sequential relative to 
the top of the file”) line numbers to lines of 
limited length (initially 80 characters), al- 
lowing the user to reference a unit of infor- 
mation. Early examples of these include 
ATS [IBM70] and VIPcom [VIP69], Sim- 
ple command languages allowed the user to 
make corrections within a line or even 
within a group of contiguous lines, using 
much the same syntax as did batch editors. 
Some early timesharing editors still re- 
stricted the user to forward access; later, 
this restriction was lifted and the user could 
scroll both forward and backward through 
a file. Typically, line editors with bounded- 
length lines shared the unfortunate prop- 
erty of truncation', if an insert or change of 
characters forced the line to exceed the 
maximum length, characters were dropped 
off the end of the line as needed. This 
implementation “feature,” stemming from 
a conceptual model of the editing process 
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based on simulating punched cards and line 
printer listings, was only marginally accept- 
able for program editing and unacceptable 
for serious manuscript preparation. (In the 
latter case, automatic creation of a new line 
upon overflow would have been a trivial 
fix.) 

Another advance was the creation of the 
context-driven line editor, which allowed 
the user to identify the line containing the 
target of an operation by specifying a char- 
acter context pattern for the editor to 
match, rather than by giving an explicit line 
number. One of the first examples of the 
context-driven line editor was the trend- 
setting editor running on the IBM 7090 as 
part of Project MAC’s CTSS [Cris65]. 
Other classic examples include IBM’s CMS 
editor [IBM69] (see Part II, Section 1) and 
Stanford’s WYLBUR [Fajm73]. At this 
point in the history of editing, users were 
still forced to think about multiline entities, 
such as paragraphs and program blocks, as 
groups of integral lines, usually in card im- 
age format; no interline commands were 
available that would, for example, delete 
text spanning from the middle of one line 
to the middle of the next line. 

The first break from the 80-column card 
image came in the form of variable-length 
line editors, typified by Com-Share’s Quick 
Editor (QED) [Deut67, ComS67], The 
main element of operation was still the line, 
but now each line could be of “arbitrary” 
length. Initially, these lines were actually 
limited to some maximum. QED popular- 
ized the notion of a “superline” (limited to 
500 characters in length), which the on-line 
display process broke into viewable lines of 
80 characters each until the superline was 
exhausted. While editing across superline 
boundaries was still impossible in these ed- 
itors, the probability that a full phrase or 
sentence that needed editing would fall 
within a single superline was much greater 
than with an 80-character limit. Later, true 
variable-length line editors removed the re- 
striction. By removing the card image ori- 
entation of the editor, the variable-length 
line editor had strong and beneficial impact 
on the versatility of text processing. An- 
other far-reaching result of the invention of 
variable-length line editors was that dis- 
played text was no longer considered to be 
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a one-to-one mapping of the internal rep- 
resentation, but rather a tailored, more ab- 
stract view of the editable elements. 

Even with superline editors, three basic 
problems in manuscript editing remained: 
truncation when the line length was ex- 
ceeded, inability to edit a string crossing 
line boundaries, and inability to search for 
a pattern crossing line boundaries. This last 
problem is an especially difficult one when 
transcribing editing changes from format- 
ted hard copy in that even a short phrase 
that appears on one line within the paper 
may be spread across two lines in the doc- 
ument’s source file, unbeknown to the user. 
Consider, for example, the familiar “the 
the” typo problem. If a document being 
edited on a line editor contained the lines 

. . . The power of the 
the stream editor . . . 

a search command 

locate/the the 

would not find the pattern “the the,” since 
it appears on two separate lines. The 
stream editor concept solved all three prob- 
lems by eliminating line boundaries alto- 
gether: the entire text was considered a 
single stream or string that was broken into 
screen lines by display routines. An arbi- 
trary string between any two characters 
could be defined for searching and editing. 
HES [Carm69], and FRESS are examples 
of stream editors. Although the TECO 
[BBN73] stream editor left the carriage 
returns and line feeds in the text stream, 
these could be edited like any other char- 
acter; they did not serve to isolate one line 
from the next in editing. In fact, the gen- 
erality of the TECO stream model has 
made possible the construction of several 
sophisticated editors using TECO as a nu- 
cleus (see Part II, Section 1). 

Another way of dealing with the limita- 
tions of line/superline editors was to use 
the power of multiline display screens, 
which provided cursor addressability and 
(possibly) local buffers, to create what are 
called synonymously full-screen, display, 
or cursor editors. These editors work either 
with variable-length lines or with streams, 
offering the user an entire screenful of text 
to view and edit without regard to line 


boundaries. An early example of a time- 
shared display editor is Stanford Univer- 
sity’s TVEDIT [Toll65, McCa67], Com- 
mands, represented by control character 
sequences, could be interspersed with the 
input of “normal” text. Users were able to 
move the cursor to point to the text they 
wished to manipulate rather than having to 
describe text arguments in some awkward 
syntax. Characters could be replaced by 
simply typing over them. Characters could 
be deleted by placing the cursor on the 
character and pressing the delete control 
character; characters to the right of the 
cursor moved left so that the cursor seemed 
to “swallow” characters. Similarly, for in- 
sertions, the characters to the right of the 
pointer moved to the right, “making room 
for the new characters. The TVEDIT con- 
cepts and similar work by Ned Irons 
[Iron72] form the basis of many screen 
editors in use today. 

A major new way of thinking about ed- 
iting was introduced as early as 1959 by 
Douglas Engelbart at Stanford Research 
Institute. His NLS (oNLine System), im- 
plemented in the 1960s to create an envi- 
ronment for on-line thinking and authoring, 
showed the power of display terminals, 
multicontext viewing, flexible file viewing, 
and a consistent user interface [Ence63, 
Enge68, Enge73]. One of the NLS project’s 
many important contributions was the 
mouse, an input device that is only now 
being integrated into commercial products. 
NLS was the first structure editor in that 
it provided support for text structure and 
hierarchy, not just for manipulating raw 
strings of text: the user could manipulate 
documents in terms of their structure, not 
only their content. 

NLS and other related systems, such as 
HES, FRESS, and Xanadu 7 [Nels74, 
Nels 81], are particularly important be- 
cause they view the editor as an author’s 
tool, an interactive means for organizing 
and browsing through information, rather 
than simply as a mundane tool for altering 
characters in a single file. 

Hansen’s EMILY [Hans 71] extended the 
concept of the structure editor and devel- 


7 Xanadu ia a registered trademark. 
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oped the syntax-directed editor , in which 
the structure imposed on a program being 
edited was the structure of the program- 
ming language itself. Users were able to 
manipulate logical constructs, such as 
do-while loops and their nested contents, 
as single units. 

In the late 1960s, general-purpose time- 
sharing facilities typically supported only 
simple interactive line-editing and batch- 
formatting facilities for line-printer output. 
These “value-added” facilities were barely 
adequate to create and modify programs 
and rudimentary documentation. By the 
early 1970s, text processing had become 
sufficiently important to be the single ded- 
icated application on both stand-alone and 
timeshared (“shared-logic”) minicomput- 
ers. Since these minicomputers did not 
need to support general-purpose computing 
facilities, manufacturers were able to offer 
comprehensive editing and formatting/ 
typesetting capabilities as well as features 
oriented toward document production such 
as database management, information re- 
trieval, work-flow management, and print- 
and job-queue management that were usu- 
ally unavailable on general-purpose sys- 
tems. For a time, owners of these systems 
often had more text-processing power than 
those with much more expensive and much 
larger general-purpose computers. Exam- 
ples of dedicated word processing systems 
include CPT, Lanier, DEC Word/11, NBI, 

' and Wang. 

An important milestone in text editing 
and text processing was the early 1970s 
development and mid 1970s acceptance of 
the UNIX timesharing system, the first 
general-purpose computing environment in 
which text utilities were given as much 
weight as programming utilities. In UNIX, 
,a suite of utilities (the ed text editor, the 
troff text formatter, the eqn equation for- 
matter, the tbl table formatter, tho refer 
bibliographic database and formatter, the 
spell spelling corrector, and the style and 
diction text analyzers [Kern82]) intro- 
duced and popularized an extensive set of 
text tools in the general-purpose computing 
community. At the same time the publish- 
ing industries— newspapers, magazines, 
wire services, the graphics arts — converted 
wholesale to electronic typesetting and lay- 
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out of pages, borrowing ideas from tradi- 
tional computer-based text processing, and 
also channeling ideas in typesetting and 
page layout back to the computing com- 
munity. 

In the then-separate area of computer 
graphics, picture editors were being de- 
signed to allow the user to manipulate 
graphical elements. Interactive drawing 
techniques from Sutherland’s pioneering 
Sketchpad system [Stmi63] were later in- 
corporated into editor interfaces. The Car- 
negie-Mellon tablet editor [Cole69] is an 
example of the use of this technology. In 
this experimental editor, hand-drawn 
proofreader’s symbols were used to edit 
displayed text. The symbols were drawn on 
a data tablet and were recognized by the 
program by passing various characteristics 
for a given symbol through a decision tree. 
For a delete or substitute operation, for 
instance, the user drew a line through the 
text to be deleted. The system deleted this 
line, blinked the indicated text for verifica- 
tion, separated the text by opening a blank 
line, and inserted a cursor, enabling new 
text to be typed in from the keyboard. For 
a transpose operation, the user simply used 
the familiar transposition mark. With the 
existence of data tablets with built-in mi- 
croprocessors dedicated to this recognition 
task [Imag81], we may expect to see this 
technique used in commercial editing prod- 
ucts in the near future. 

The major innovations of the 1970s in 
text handling and the user interface, specif- 
ically the Bravo editor [Lamp78] and the 
Smalltalk environment, took place at Xe- 
rox’s Palo Alto Research Center (Xerox 
PARC). These systems demonstrated the 
expressive power of blending text and 
graphics on a high-resolution, bit-mapped, 
raster graphics screen, using a dynamic 
graphical interface provided by a dedicated 
personal computer. Editing was done by 
selecting items on the screen, using the 
mouse as a pointing device. These systems 
were also the first interactive editor/for- 
matters, in which the user’s text was dis- 
played on the bit-mapped screen in a fac- 
simile of the typography and layout of the 
final document, as the document was being 
input or modified. For the first time, the 
user was given a notion not only of the up- 
! 


to-date content, but also of the up-to-date 
form of the document. 

Current research in the field of editing is 
focused upon several overlapping areas. 
One is that of providing a consistent, editor- 
based interface throughout a computer sys- 
tem [GolA79, Lant80, FbakSO, Ai*ol81, 
Stal81, Tesl81, GolA82], This allows 
many common functions, such as renaming 
files, searching through directories, and de- 
bugging programs, to be performed as ed- 
iting operations. For instance, to rename a 
file, one would type over the old file name 
in a listing of available files that would 
appear on the screen; in debugging a pro- 
gram, one would be able to edit the values 
of displayed variables. Other research top- 
ics include generalized structure editors, 
powerful syntax-directed editors with pro- 
gram-tracing capability, and interactive ed- 
itor/formatters. Research in these and 
other areas is discussed more fully in Part 
II, Section 1. 

3. FUNCTIONAL CAPABILITIES 

In this section, we take a more detailed look 
at interactive editors, examining their func- 
tional capabilities from a user perspective. 

3.1 Traveling 

User-specified traveling commands cause 
the current editing and viewing pointers of 
the editing and viewing components to be 
moved, resetting the filters that extract the 
editing and viewing buffers. 8 Traveling 
ranges from simple motion such as moving 
to a subsequent screenful of data, to more 
complicated movements such as pattern 
search and tree or directed-graph traversal. 

Early systems, and even many of today s 
word processing systems, are oriented to- 
ward transcription of editing changes from 
hard copy. They therefore provide rela- 
tively unsophisticated traveling mecha- 
nisms. For on-line authoring, however, a 
system should be oriented toward browsing, 
studying, and organizing as well as toward 
composition and revision. In such a system, 
traveling flexibility and power are manda- 


«To simplify the remainder of our discussions, wo 
group both pointers together under the term ''current 
pointer.” 


tory, as the NLS experience has shown 
[Enge68]. 

3.1.1 Simple Movement 

Editors commonly support two types of 
intrafile motion: absolute and relative. An 
absolute specification indicates a destina- 
tion independent of the current position, 
while a relative specification indicates the 
destination relative to the current position. 
Generally, the current pointer is main- 
tained internally to point to the correspond- 
ing current position in the data structure, 
in editors with pointing devices, the cursor 
usually points at this position in the visible 
text with the current pointer in lockstep. 
The user can move the editing buffer and 
viewing buffer from this position by issuing 
simple commands. In IBM’s line-oriented 
CMS editor, moving the editing buffer and 
the viewing buffer five lines ahead in the 
document would be accomplished by typing 

next 5 

In line-oriented editors, line numbers can 
be fixed or varying. In editors with fixed 
line numbers and numeric labels provided 
by the user or the system, the user can 
easily specify an absolute goto to that num- 
ber. As an example, the editor portions of 
BASIC interpreters use fixed line numbers 
specified with even intervals, such as 

00010 FOR I = 1 TO 10 
00020 J = I ’ I 
00030 NEXT I 

To add a print statement after the incre- 
ment statement, one could simply type 

00025 PRINT I, J 

and the editor would put the new line be- 
tween lines 20 and 30, as indicated by its 
numeric label. 

In contrast, editors with varying line 
numbers keep track of a line’s position in- 
ternally as an offset from the top of the file. 
When a new line is added, the internal line 
numbers of all lines beneath the new line 
are incremented by one. Since the line num- 
bers change dynamically, the deletion (in- 
sertion) of a line near the top of the file 
causes all the line numbers below it to be 
decremented (incremented) by one. Be- 
cause of this, editing by specification of line 
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number is best done from the bottom of the 
file upward, since insertions or deletions 
will typically only affect the lines at and 
below the current pointer. This is a restric- 
tion palatable (if at all) only for trans- 
cription from hard copy, not for on-line 
revisions. 

As we have seen, the user of a display 
editor travels by pushing function keys 
such as 

L». jjfaij - r< 

4- LINE or -LINE 

+ WORD. or -WORD 

4-PAGE or -PAGE 

4-1/2 PAGE or -1/2 PAGE 

that effectively change the contents of 
the editing buffer and the viewing buffer. 
Additionally, the editing and viewing 
buffers can be moved left or right by a 
specified number of character positions 
(columns) to allow editing of wide lines, as 
in the following command: 

50 LEFT 

Top and bottom (of file) are two very com- 
mon, highly functional traveling com- 
mands. 

Many editors have mark or saved-posi- 
tion stacks or rings that record locations in 
the file. Some maintain an implicit mark 
ring, automatically storing the location 
each time that the user makes a selection 
for a command, and allowing the user to 
retrace his or her steps. Others have explicit 
mark buffers; the user uses the save posi- 
tion command to store the current location 
in any number of buffers and the goto 
position to return to a saved position. Ad- 
ditions or deletions in the file will throw off 
the exact saved location if the editor only 
saves a character-pointer or line-pointer or 
other varying index, but will typically leave 
the user in a location close to the original 
marked location. 

Systems like NLS and FRESS allow 
character string labels to be inserted in the 
text; these move as the adjacent text is 
moved. The user need not know the loca- 
tion of a piece of text, whether relative or 
absolute, in this system, but, for example, 
can travel instantly to the text labeled 
"casestudy” with the command goto-label 
casestudy. In the case of program editors, 
identifiers in procedure declaration state- 
ments can be used as implicit labels, as in 
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the EMACS tags facility explained in Part 
II, Section 1. 

Of course, many target-dependent trav- 
eling operations exist. In document editors, 
for example, simple movements are pro- 
vided to bring a user to the beginning of a 
section or chapter. In a program editor, a 
traveling command might take the user 
to the next syntactic element. More 
specific examples are provided in Part II, 
Section 1. 

3.1.2 Pattern Searching 

The above methods of traveling are posi- 
tion dependent: goto line 7, go-back 15 
lines, or goto-label sec5. Almost all modern 
text editing systems additionally allow a 
content-dependent specification of loca- 
tion: pattern searching. A pattern search- 
ing command (usually called search, find, 
or locate) generally changes the editing and 
viewing buffers so that they contain the 
pattern that is being sought. 

Since typing an entire pattern is a tire- 
some operation, specification aids have 
been developed. The familiar “ . . . ” ( ellip- 
sis ) construct can be specified to abbreviate 
a long pattern by indicating simply a few 
characters of context at the beginning and 
end of the pattern. Thus, one can locate the 
text string: 

Now Is the date for some good men 
with the command: 
locate /Now . . . men 

Regular expression context patterns ex- 
tend the ellipsis concept to more powerful 
pattern-matching capabilities, for instance, 
matching a pattern that does or does not 
contain a particular set of characters, 
matching a pattern only if it occurs at the 
beginning of the line, or matching a pattern 
regardless of the case of the characters 
(known as case-insensitive pattern match- 
ing). 

3.1.3 Interfile Motion 

The ability to travel between two or more 
files is extremely useful in on-line author- 
ing. At the least, the user must be provided 
with commands to switch between two files. 
(This is much more useful, of course, if the 
V 
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two files can be displayed in two windows 
on the screen.) More advanced editors 
maintain a circular list of the files visited; 
the user can travel from one to the next or 
the previous in an ordered fashion, or in 
some cases choose any of the files from a 
display of the circular list. 

Interfile travel generates several new 
problems. An editor may need a more in- 
tricate internal data structure and associ- 
ated editing and viewing buffers for each 
open file to allow multiple files to be active 
at once. If the editor has the ability to map 
file viewing buffers to multiple windows, 
but can only keep track of one file at a time, 
a file must be saved each time the user 
switches windows; this discourages on-line 
browsing. As well, attributes can be kept 
for each file so that when a user is editing 
a LISP program, the editor matches paren- 
theses and automatically indents lines. 
When the user returns to a textual docu- 
ment, the editor should no longer do so. 

3.1.4 Hypertext and Trails 

The above types of travel are usually em- 
ployed by the user during the editing of a 
document, typically to get to the next place 
in the file where an edit is to be performed; 
the paths of travel are not stored from 
one editing session to the next. Occasions 
do arise when the user wants to set up 
(semi-) permanent paths or links within a 
document or between documents. The mo- 
tivation for such text links is well stated in 
a seminal article by Vannevar Bush, who 
envisioned the “memex” device for authors 
and readers in 1945: 

The human mind . . . operates by association. With 
. one item in its grasp, it snaps instantly to the next 
that is suggested by the association of thoughts, in 
accordance with some intricate web of trails carried 
by the cells of the brain. It has other characteristics, 
of course; trails that are not frequently followed are 
prone to fade, itoms are not fully permanent, mem- 
ory is transitory. Yet the speed of action, the intri- 
cacy of trails, the detail of mental pictures, is awe- 
inspiring beyond all else in nature .... Consider a 
future device for individual use, which is a sort of 
mechanized private file and library. It needs a name, 
and, to coin one at random, “memex” will do. A 
memex is a device in which an individual stores all 
his books, records, and communications, and which 
is mechanized so that it may be consulted with 


exceeding speed and flexibility . . . when numerous 
items have been thus joined together to form a trail, 
they can be reviewed in turn, rapidly or slowly, by 
deflecting a lever like that used for turning the pages 
of a book .... It is exactly as though the physical 
items had been gathered together from widely sep- 
arated sources and bound together to form a new 
book. It is more than this, for any item can be joined 
into numerous trails. [Busil45, pp. 106-107] 

Hypertext editing systems are the mod- 
ern-day incarnation of Bush’s precomputer 
memex. Hypertext, a term coined by Ted 
Nelson is “the combination of natural lan- 
guage text with the computer’s capacities 
for interactive branching, or dynamic dis- 
play ... a nonlinear text . . . which cannot 
be printed conveniently ... on a conven- 
tional page” [Nels67, p. 195]. Simply, hy- 
pertext is defined as nonsequential writing. 
Hypertext systems allow the user to con- 
struct arbitrary links from any chosen point 
in a document to any other point in that 
document or in any other document in the 
user’s domain. Menus of such links can be 
set up to provide a branching text that 
constantly evolves to provide a “dynamic 
and plastic structure” [Enge68], A batch 
formatter can follow keyword-specified 
links to compile the text needed to produce 
a document. An interactive user can select 
links by keyword specification or by menu 
selection to lead to desired text, typically 
displayed in a separate window. In NLS, 
links can also be accessed via complex spec- 
ifications of structure and/or content. One 
can specify, for example, “follow the first 
link containing the string ‘edit’ in any third- 
level statement in the hierarchy, starting 
the search at the current first-level state- 
ment in view.” 

In the simplest sense, a hypertext docu- 
ment can consist of a “table of contents” 
with on-line links to files containing each 
chapter, each of which can link to sections. 
More advanced forms of hypertext include 
the use of links, rather than the on-line 
equivalent of standard footnotes, to point 
to the actual material referenced, allowing 
instantaneous access to cited material. 
Thus a document can be browsed on-line, 
and predesigned-but-optional diversions 
can be set up along trails that readers may 
find interesting. Of course, authors and 
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Main Text 


Annotations 


This is a 
footnote to the 
art icle. . . 


TAGS 


SESSION 2 OF 
TENNYSON 
%J1 Biographies 
Informat ion%%... 
XJ2 Critical 
RrMc I •«%%... 


%P from 2nd session%% 
R Discussion of 
Imagery In 


JUMPS 


%P from 2nd 
sessionXX 
B I ography 
of Tennyson 


%P From discussion 
of Imagery 


Figure 4. An example of hypertext in FRESS. Tags and jumps are two of FRESS’s 
hypertext elements. A tag T points to a single element (such as a footnote) in an 
"annotation space”; the user views the annotation but remains in the main text. A jump 
J indicates a path to another part of the current document or to another document. By 
taking a jump, one travels, changing the editing and viewing buffers of the document. In 
the new context, one can edit, take another jump, or take the reverse of a jump (labeled 
P for pmuj t jump spelled backward), which returns to the unique source of the J that 
brought the user to the P in the first place. Multiple jumps to the same text would have 
multiple P labels so that the user could distinguish the sources. Other system commands 
allow the user to retrace steps on a session basis, that is, to return from all previous 
jumps with explicit return commands. 
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Figure 5. Electronic book layout. A multiple-window display in the document 
layout system designed for authors and readers. The author may traverse the 
document’s structure independently in each window and make links between chap- 
ters and pages in different windows. The author may also create, resize, and remove 
windows as needed, and revise the level of detail of the pages and chapters shown to 
control the amount of information presented. 


nent creates an up-to-date view on the dis- 
play. The viewing operations are of three 
sorts: (1) filtering operations in which ap- 
propriate portions of the raw data structure 
of the file are selected for the viewing 
buffer, (2) operations that format these fil- 
tered data to produce an ideal view, and (3) 
operations that map this ideal view to a 
window or page on a physical output device. 

3.2.1 Filtering 

Editors that are especially oriented toward 
browsing (e.g., NLS and FRESS) usually 
provide facilities to alter the viewing spec- 
ifications ( viewspecs ), allowing the user to 
control the filtering operations. Viewspecs 
can be used to control any number of selec- 
tion and viewing parameters (parameters 
controlling what is to be displayed and how, 
respectively) to effect information hiding 
and on-line formatting. For instance, NLS 
allows the user to indicate what levels of 
detail in a hierarchy are to be displayed, as 
well as how many characters per statement 


and even which statements, on the basis of 
content specification (e.g., “fill the window 
with the first 50 characters of as many of 
the statements that lie between Sections 
1.3 and 1.9 as possible, up to and including 
the third decimal level”). Additionally, the 
viewspecs control whether the selected text 
is to be shown normally or in indented 
outline form, with or without section num- 
bers, with or without format codes, or in 
ragged-right or right-justified format. Dis- 
play keyword or password viewspecs allow 
the user to see pieces of text only upon the 
presentation of the proper key; this facility 
can he used to protect sensitive materials 
and to reduce the clutter of on-line presen- 
tation by presenting only (potentially) rel- 
evant information. Similarly, a syntax-di- 
rected editor can allow the user to turn off 
the display of declarations or comments in 
a program. 

Since the view is a mapping of the inter- 
nal data structure onto the user’s display, 
external factors such as noise on the com- 
munications line or a received system mes- 
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rage can corrupt the displayed view, while 
the internal data structure remains intact. 
A system often supplies a refresh display 
function to restore the appropriate view 
from the internal data structure. 

3.2.2 Formatting 0 

The simplest method of formatting the fil- 
tered viewing buffer contents is the “null” 
formatting: the text is shown exactly as it 
is stored in the internal data structure. Typ- 
ically this is not sufficient for the user. In 
simple editors, text is stored essentially as 
consecutive characters on disk, with special 
characters indicating tabs and physical 
ends of lines. A simple formatting routine 
is needed to map stored lines to a screen 
image, inserting logical carriage returns 
and/or line feeds where appropriate. In 
many editing systems, especially stream ed- 
itors, the formatting routines must make 
on-the-fly decisions about where to break 
lines that do not fit on one screen line 
[Knut79, Achu81], For program editors, 
an intelligent formatting routine might in- 
clude automatic indentation of program 
constructs. 

In early text processors, formatting codes 
(such as .pp for paragraph, .in 5 for indent 
five spaces, .ce for center) were typed in as 
literal text and subsequently compiled in a 
batch-formatting pass to produce format- 
ted pages; no on-line feedback was avail- 
able. Later soft-copy or proof-copy facilities 
were made available to display (but not to 
allow editing of) monospace (line-printer 
quality): output on the alphanumeric ter- 
minal., With high-resolution point-plotting 
and raster displays, even proportionally 
spaced typeset text could be previewed out- 
side the editor as the result of a separate 
batch formatting pass. The next major step 
in the 'formatting field was the creation of 
the interactive editor/formatter. Today 
most editors, especially commercial word 
processors, instantaneously display the re- 
sults of commands with local effect (such 
as indent, tab, embolden, and center) as 
they are entered or changed. In the newest 

' We do not attempt to cover the entire field of for- 
matting here, but simply point out salient features of 
formatting directly tied to the editing task. We refer 
reader* to Furu 82 for a thorough survey. 

Computing SnrvM- 


generations of word processing systems the 
idea of on-the-fly formatting has been taken 
to the next logical step: they allow essen- 
tially all formatting, including hyphenation 
and pagination, to be done on the fly. In- 
teractive editor/formatters make possible 
an especially useful view in which all oper- 
ations on the document take place imme- 
diately on a displayed facsimile of the 
printed page, thus giving instant user feed- 
back. Other optional views may include the 
facsimile document along with ancillary 
windows in which the typesetting codes 
controlling the formatting are displayed 
(see the description of the Xerox Star in 
Part II, Section 1), or with in-line “tags” 
describing the various document elements 
that appear on the screen (see the descrip- 
tion of ETUDE in Part II, Section 1). 

With hardware such as the personal work 
station becoming prevalent, users will be 
less patient with traditional, tiresome, mon- 
ospace characters on 80 x 21 CRTs, and 
will demand that display output make use 
of the many hard-copy information-coding 
techniques that improve reading efficiency. 
These include proportionally spaced text, 
font changes, higlilighting, complex page 
layout, and even embedded equations and 
graphics. Thus on-line formatting for dis- 
play (soft copy) and off-line formatting for 
paper (hard copy) will become more simi- 
lar, especially when bit-map raster displays 
approaching the 200-points-per-inch reso- 
lution of inexpensive (less than $10,000) 
electrostatic or laser printers become com- 
monplace. (Even before this becomes a 
reality, we see that computerized typeset- 
ting, once reserved for special documents 
or for final copies of a document whose 
drafts were produced on line printers or 
typewriter terminals, is now within the 
reach of many commercial and academic 
installations for routine work.) Editors 
must therefore make it possible for the user 
to specify sophisticated formatting effects 
shown on-line during the editing phase. 
Good examples of systems providing inter- 
active typesetting can be found in several 
works in the literature [Lamp78, Hamm81, 
SeyJ81, Smit82, Xero82]. 

3.2.2.1 Formatting Commands. Ap- 
proaches to the specification of formatting 
are numerous. In some systems, primitives 
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PARAGRAPH PROPERTIES 
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Figure 6. Xerox Star property sheet. The Xerox Star property sheet allows the 
user to edit attributes of various elements. The paragraph property sheet lets the 
user change alignment, spacing, and hyphenation by pointing at graphical buttons 
on the screen. Selected attributes are shown in reverse video. (From Xf.ro 82, 
courtesy Xerox Corporation.) 



provided as part of the interaction language 
allow the user to specify formatting opera- 
tions on designated elements. For instance, 
the use of the center command in the editor 
might actually insert the appropriate spac- 
ing for centering and alter the internal rep- 
resentation of the document. Alternatively, 
this type of specification may be used to 
generate a low-level representation such as 
a formatting (typesetting) code that is 
stored in the file. In some systems these are 
invisible to the user and a mechanism must 
be provided to change these low-level rep- 
resentations using high-level editing com- 
mands. For example, many word processors 
provide a tab rack, an on-screen simulation 
of a typewritter’s margin and tab controls, 
that contains the current margin settings, 
font styles, tab stops, and so on. The user 
can change these settings by simply moving 
the cursor into the tab rack and editing the 
attributes. In Xerox’s Star, alternatively, 
every element (from a single character up 
to the entire document as a whole) has 
associated with it an optionally displayable 
property sheet , which simulates a pre- 
printed form or checklist. The user can 


examine the property sheet at any time and 
fill in or change the stored formatting op- 
tions for any element (see Figure 6). 

In other editors, the formatting specifi- 
cation is entered as a formatting code in 
the same manner as “normal” (literal) text. 
In some systems, these codes must be en- 
tered on separate lines to distinguish them 
from literal text; in other systems a special 
character is used as a delimiter so that the 
codes can be imbedded in the normal text 
stream; two delimiters in a row then desig- 
nate a literal delimiter character. 

Regardless of how they are indicated, the 
specifications are one of two types: proce- 
dural or declarative (markup). In a pro- 
cedural specification, the author indicates 
the exact operations to be done to effect 
the formatting choices (e.g., skip two lines 
and indent three spaces). Conversely, in a 
declarative system, tags are used to identify 
elements of the document, such as items in 
a numbered list, paragraphs, chapter head- 
ings, and running heads. A separate facility 
stores the actual formatting attributes for 
the particular elements, and the formatter 
recognizes the tags and uses the tag facility 
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(usually a set of formatting macros or a 
database of formatting information) to de- 
termine how to format any part of the 
document. These tags allow the same doc- 
ument to be formatted in different styles or 
for different output devices by simple par- 
ameterization: for instance, the user could 
format a Computing Surveys document by 
specifying the tag (Style = Surveys) at the 
beginning of the document and for Com- 
munications of the ACM by specifying the 
tag (Style = CACM). Similarly, the user 
could format a document for the line printer 
by specifying the device tag (Device = Ipr) 
and for a high-quality typesetter by speci- 
fying the tag (Device = typesetter). Style 
sheets containing a skeleton of tags for a 
particular document, for example, an on- 
line corporate memo that can be filled in by 
users, allow standardization of documents 
for a community, much like preprinted sta- 
tionery or pads. Declarative languages pro- 
vide less complicated user specifications, 
and often less complicated editor interfaces 
for on-line formatting; the user need not 
supply detailed formatting commands, and 
need use only high-level structural indica- 
tors as tags. Reid’s Scribe [Reid808, 
REiD80b, Reid80c] is a popular declarative 
language and document compiler. IBM’s 
GML [GolC 81] is a formatter-independent 
declarative language. Hammer et al. 
[Hamm 81], Walker [WALK81b], and Cham- 
berlin et al. [Cham 81] discuss editors that 
make use of the declarative technique (see 
Part II, Section 1). 

3.2.3 Window Manipulation 

In editors with multiple windows, the user 
must be able to specify and alter the place- 
ment of the windows on the display. 
Though the system can allocate windows— 
a single window could occupy the entire 
screen, two windows, half the screen each, 
and so on — the system can allow the user 
to -specify the windows, either by typing 
coordinates or, more likely, by defining the 
bounds with a pointing device. 

3.3 Editing 

Our discussion of the editing component 
focuses on two major concerns: specifying 
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the operands of an editing command and j 
the operations themselves. 


3.3.1 Specification of Scope 

The range of a document used as an oper- 
and for an editing operation is called its 
scope. The user typically thinks of the 
scope not in terms of “raw" text, but rather 
in terms of logical elements that can be 
both edited and traversed. These elements 
are also known as units, nouns, objects, and 
structures, and are often a function of the 
internal representation of the target data. 
In line editors, for example, manuscript text 
may be stored as sequential lines and edited 
and traversed on a line basis. In stream 
editors, the text may be stored as a one- 
dimensional, indefinitely long stream of 
characters, broken into discrete lines by 
formatting routines for viewing purposes. 
Programs may be stored in textual form or 
. in some intermediate form such as a parse 
tree or abstract syntax tree. 

In addition to logical elements that 
match the internal representation, editors 
provide a variety of elements corresponding 
to user-level abstractions, often grouped in 
order of increasing scope: characters, 
words, lines, sentences, paragraphs, and 
sections are typical for text. In addition to 
these standard system-provided elements, 
users can also define arbitrary regions or 
blocks that exist only for the duration of a 
given operation. A third class of elements 
may be a (partially overlapping) set of ab- 
stract document components such as sec- 
tions, headings, titles, running headers, 
footers, and numbered lists. These are typ- 
ically defined in terms of formatting 
conventions and are available for explicit 
manipulation only in the most recent 
editors. 

The goal of scope specification for all 
these elements is to approximate within the 
limitations of the computer interface the 
ways users would manually gesture (“delete 
this, move that over there”). As we have 
seen, in line editors the user establishes the 
current line (by specifying its fine number 
or by traveling to it via scrolling or pattern 
searching) and then specifies the scope (by 
typing either a context pattern within that 
line or an integer to indicate a group of one 
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or more discrete lines whose first line is the 
current one). In the UNIX ed editor the 
command 

s/Julius/Brute/ 

substitutes the word “Brute” for the scope 
"Julius” when the user is at the line 

Et tu Julius! 

In stream editors, of course, the pattern 
matching is not limited to a current line but 
has potentially the entire file as its domain. 
In display editors, the user specifies the 
scope by driving a cursor with a locator 
device to define the appropriate element(s), 
in a manner more directly analogous to the 
manual technique of pointing. 

There are several techniques for speci- 
fying a scope, some applicable to a typing- 
oriented interface, some applicable to a 
pointing-oriented interface, and some ap- 
plicable to both. 

In the first technique, the user simply 
selects an element — a character, word, line, 
or paragraph, for example. The user may 
extend this selection by selecting another 
element of this same type; all elements 
between the starting point and the other 
selected point (inclusive) would be selected. 
This is typically done using the ellipsis or 
regular expression facilities in a textual in- 
terface, and direct cursor positioning in a 
pointing interface. 

In the second technique, the user adds 
modifiers to the commands. For example, 
having established a location in the text 
with context or cursor specification, the 
user can complete or modify the scope of a 
delete operation with word to form delete 
word or with a numeric parameter to form 
delete 3 words. 

In the third technique, the user again 
establishes a starting selection at the small- 
est element (e.g., a character) and then 
adjusts the selection. For instance, by using 
the mouse in Xerox’s Star, a character can 
be selected as an initial scope and this scope 
adjusted to include successively the word, 
the line, the sentence and the paragraph 
containing that word (see Figure 7). 

In a hierarchical structure editor, selec- 
tion and adjustment can easily be used to 


traverse the hierarchy, as in select node 
and extend to left child. 

3.3.2 Editing Operations 

3.3.2. 1 Creating. Text is inserted into a 
computer-based document with a text input 
device. To enrich this hardware, special 
software is frequently supplied. Editors of- 
ten provide automatic wordwrap, which 
eliminates the need for typing a carriage 
return at the end of each line. When the 
editor senses that the word currently being 
typed has exceeded the right margin, it 
breaks the line at the first blank space 
before the overflowing word and automati- 
cally pushes it, followed by the cursor, to 
the next display line. 

Display editors generally offer one of two 
kinds of input styles: typeover mode or in- 
sert mode. In typeover mode, each typed 
character replaces the character at which 
the cursor is pointing. For adding charac- 
ters, such editors must supply insert char- 
acter or insert line functions that open a 
blank character or a blank line at the cursor 
position. In insert mode, each time a user 
types a character, the character at the cur- 
sor position and all those to its right are 
shifted right one character and the typed 
character is inserted at the cursor position. 
Thus insertion can always be done without 
any commands, while replacement requires 
a command such as delete character or 
delete line before or after the insertion. 
Many editors allow the user to toggle be- 
tween typeover mode and insert mode. 

Other creation techniques include the ca- 
pability of embedding files or parts of files 
into the document being edited, thus mak- 
ing it possible to recycle previously created 
material. The user can create boilerplate 
documents, as is often done with proposals, 
contracts, and specifications, by using bits 
and pieces from the entire domain of user 
files on the computer. Form letters can be 
created by embedding consecutive ad- 
dresses from an address file at the top of a 
generic letter file. 

3.3.2.2 Deleting. The delete command 
requires the user only to select the scope of 
the operation. Since deletes are obviously 
dangerous commands, some systems re- 
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Figure 7. Selection in Star. One dick of a mouse button selects a character, the second click adjusts the 
selection to be the word containing that character, and the third click adjusts to the sentence containing that 

word. ■ i< 


quire confirmation before actually complet- 
ing the operation. Other systems allow the 
user to undo commands, making the dele- 
tion' operation reversible. For the delete 
command, as well as the copy and move 
commands described below, many systems 
provide delete buffers. This allows the de- 
leted elements to be placed in “limbo" so 
that they can be used later as the objects of 
put (also called insert) operations, which 
put the elements from the delete buffer 
back into the text. To move a paragraph, 
for instance, the user first selects it and 
specifies the delete operation; the editor 
then deletes the paragraph and places it in 


the delete buffer. To put the paragraph 
back in somewhere else, the user indicates 
the desired destination and specifies the put 
operation. Often, systems provide multiple, 
named delete buffers for more complex ma- 
nipulations. Berkeley’s vi editor [JoY80b], 
for instance, has a buffer stack, which keeps 
track of the last nine pieces of text that 
have been deleted. EMACS [Stal80, 
Stal81] has a kill ring, a circular list con- 
taining the last eight blocks of text that 
were deleted. The user can “walk around" 
the previous kills in this ring until the de- 
sired text is found, with the walk always 
leading back to the starting point. Usually 
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delete buffers and kill rings are saved while 
performing interfile editing, so that text 
deleted from one file can be inserted into 
another easily. 

3.3.2.3 Changing. Many of the changes 
made to a document are corrections of ty- 
pographical and other minor errors. The 
simplest change is the replacement of one 
letter with another. In typeover mode of a 
display editor, the correction is made by 
simply typing the new character over the 
erroneous one. In insert mode of a display 
editor, the correction is made by typing the 
new character and then using a delete-char 
command to delete the old character, which 
has been pushed to the right by the inser- 
tion of the new character. Similarly, chang- 
ing a word in typeover mode simply in- 
volves typing over the erroneous word. 
However, since the replacement word may 
be shorter (longer) than the original word, 
a delete (insert) character function may 
also be needed. In insert mode, changing a 
word would be done entirely with the im- 
plicit insertion combined with delete-word 
functions. 

In editors without cursor keys, the user 
needs a method of specifying what charac- 
ter^) to replace. These editors have a 
change or substitute command, as shown 
previously, that takes as arguments both 
the scope of the change and the replace- 
ment string. 

Because of its speed, the computer can 
offer the facility of global operations— op- 
erations that take place uniformly through- 
out a document. The global change com- 
mand allows the user to specify a pattern 
to be found throughout a document and a 
replacement string to replace that pattern 
wherever it appears. In some systems, this 
command may do its work but not indicate 
what changes have been made. In others, a 
count of the number of changes is given. In 
others the pattern string is highlighted each 
time it is found, and the user is prompted 
to indicate whether or not the change is 
desired. Column-dependent changes are 
useful for editing programs or tables. 

The transpose command is a special-pur- 
pose change command. In EMACS for ex- 
ample, the CTRL-T command will exchange 


the character at which the cursor points 
with the one directly to its left, and simi- 
larly, the META-T command will do so for 
words. 

3.3.2.4 Moving. The ease with which 
blocks of text can be rearranged is one of 
the great advantages of interactive editors. 
To move a block of text the user specifies 
a source (the scope of text to be copied) 
and destination (the place where the text is 
to be copied). In an editor in which the 
scope is specified by pointing, the user de- 
fines the source by selecting the beginning 
and end of the text to be moved, and then 
defines the destination by pointing to the 
location at which it should be placed. 

In line editors and context editors, where 
such a physical sequence of steps is impos- 
sible, the user must resort to textual speci- 
fication. For example, the misordered poem 
by Frost 

Two roads diverged in a yellow wood, 

And looked down one as far as I could 
To where it bent in the undergrowth; 

And sorry I could not travel both 
And be one traveler, long I stood 

could be ordered properly with a typical 
line editor by traveling to the line “And 
looked down one as tar as I could” and 
specifying 

move 2 down 2 

This would temporarily delete the following 
two lines, including the one currently being 
pointed to, thereby moving the current 
pointer to the line following the last line 
deleted, then move it down two more lines, 
and insert the temporarily deleted lines 
where the current pointer now points. 

Note that with most line editors, the user 
is severely limited to moving integral num- 
bers of lines, rather than arbitrary regions. 
In a context-driven stream editor this spec- 
ification is a bit easier: 

move/And looked . . . undergrowth;/stood/ 

Rather than specify relative line numbers, 
the user now specifies context patterns. 

Note that systems with delete buffer fa- 
cilities may have no need for a special-pur- 
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pose move command, since, as discussed in 
the previous section, one can delete the 
desired text and reinsert it in the appropri- 
ate place with a put command. 

3.3.2.5 Copying. A copy command is 
simply a move command in which the 
source text is not removed after the desti- 
nation text is in place. 

An alternate strategy for the copy com- 
mand is to have a pick command that stores 
a selection of text in a pick buffer. This is 
analogous to using the delete buffer de- 
scribed above, with the important excep- 
tion that the picked text is not deleted. 
Now a copy of the picked text is in limbo in 
the pick buffer and can be reinserted in the 
text with the put command. If the put com- 
mand does not erase the contents of the 
pick buffer, this facility can be used to make 
multiple copies of selected text quickly. 

■ • ; 

3.4 Miscellaneous Capabilities 

Commands grouped under this heading are 
not directly involved with manipulating 
text, but rather with assuring the integrity 
of a user’s work and with making the user 
interface more powerful and helpful. 

; 

3.4.1 Reliability 

■ ■ - 

3.4.1.1 Backup Capability. To minimize 
thie possibility of the accidental erasure or 
destruction of a document, editors often 
have backup capabilities. One strategy is to 
give the user work files, copies of the actual 
files, to work with, saving them as the ac- 
tual files only when the user exits or when 
ah' autosave feature copies the work files as 
the actual files after a (user-specifiable) 
number of keystrokes or command execu- 
tions. A similar strategy is to make auto- 
matically a backup copy of the files as they 
exist when the editor is invoked; the user is 
given the actual files to edit, but can always 
make the' backup copy become the actual 
file in the case of a system crash or editing 
mishap while editing the actual file. An 
abort command allows the user to scrap an 
editing session and return to the backup 
Copy that contains the file as it was when 
the editing session began. 

3.4.1. 2 Undo Facility. The undo facility 
is a critically important, time-saving, and 


unfortunately not yet universal feature. 
The most basic version allows the user to 
undo the last command entered. More use- 
ful systems have an n-level undo stack that 
allows the user to undo commands n levels 
back (sometimes lo the beginning of the 
session or even back to previous sessions). 
The undo feature frees the user from the 
burden of making sure that each command 
does exactly what is wanted by guarantee- 
ing that any result can be undone. The 
general undo facilitates risk-free experi- 
mentation, which is especially important 
for on-line composition and organization. 
Some systems [Arch81] provide an undo- 
redo facility, which allows the user to undo 
operations and then redo them at the push 
of a button. Another way of presenting 
undo, rather than as a complete backtrack- 
ing of a session, is simply as a command 
that performs the inverse of the last speci- 
fied command. For instance, after one per- 
forms a delete, the undo command would 
essentially perform a put. Issuing undo 
again would then perform a delete. Small- 
talk-80’s cancel/accept pair allows the user 
to accept the editing state at a point in 
time and experiment freely, knowing that 
a single cancel command will return the 
document to the accepted state. 

3.4.1.3 Cancel Facilities. The cancel 
command allows the user simply to cancel 
the command that is currently in progress. 
This is of great importance if time-consum- 
ing operations such as pattern searching 
have been specified erroneously. When 
commands are not queued and type-ahead 
is not in effect, specifying a new command 
while a previous command is still executing 
often implicitly cancels the executing com- 
mand. Alternatively, especially when an op- 
eration is simply a traveling command 
rather than a command that makes exten- 
sive changes to the internal data structure, 
specifying a command while one is execut- 
ing could cause feedback from the first Com- 
mand to be canceled. For example, if the 
user presses the + PAGE key in a screen 
editor, and, while the new page is being 
displayed, the user presses + PAGE again, 
an intelligent system would not first com- 
plete the display of the first page and then 
replace that completely with the second 
page, but would cancel the display of the 
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savetemp=1 

bufinfile=.bbbuf 

bufoutfile=.bbbuf 

filename=macrofig.me 

curcrypt=0 

curstream=1 

curtabln=0 

curtabout=0 

curlndent=1 

curllne=1 9 

curchar=43 

cur8creon=0 

curmargln=0 

curwlndow=0 

curreadonly=0 

curlanguage=roff 

fileid=1 0 

Pfilename=dopstitle.tex 

Pcrypt=0 

Pstreain=1 

Ptabin=0 

Ptabout=0 

Pindent=1 

Pline=1 7 

Pchar=0 
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Pscreen=7 

Pmargin=0 

Pwindow=0 

Preadonly=0 

Planguage= 

Pfileid=1 0 

Qfilename=/usr/info/b.help 

Qcrypt=0 

Qstream=0 

Qtabin=0 

Qtabout=1 

Qindent=1 

Qline=0 

Qchar=0 

Qscreen=0 

Qmargln=0 

Qwindow=0 

Qreadonly=0 

Qlanguage= 

Qfileid=2 

Asearch=shar 

Arsearch=~[WM] 

Afsearch= 

Aexit= 

Abfsave= 


Figure 8 Abb control file. The control file saves information from one editing session 
to another. Here, for example, the bufinlile and bufoutlile variables indicate where the 
pick and delete buffers are to be saved from session to session. Curline and curchar 
indicate where in the document the cursor was pointing when the session was ended. 
Curscreen indicates which line is at the top of the screen. Filename indicates what file 
was being edited at the time the session was ended. The variables beginning with P and 
Q keep track of the same information for multiple files. 


first page and proceed to display the second 
page. 

3.4.1.4 Keystroke History. The keystroke 
history is a powerful reliability mechanism 
that keeps a copy of every keystroke (both 
command and text) that the user has spec- 
ified since the current editing session 
started. If the system crashes, the user is 
provided with mechanisms to run the key- 
stroke history file against the old copy of 
the edit files as if the commands were being 
typed in. This history file can also provide 
the basis for the undo command. 

3.4.1.5 Context Saving. A useful feature 
provided by some systems is the ability to 
save editor attributes and parameters from 
session to session. In bb, for example, a 
control file (see Figure 8) saves data about 
the initial cursor position when the editor 
is invoked, the file to use, and enough other 
information that the user can simply invoke 
the editor, without any parameters, and 
continue a session exactly where it ended 


five minutes or five days ago. In more 
advanced systems, a checkpoint/ restart, 
snapshot, or workspace facility allows the 
recording and subsequent restarting of the 
entire editing environment, including com- 
plete internal data structures. This is com- 
mon in programming languages like LISP, 
APL, and Smalltalk-80. 

3.4.2 Ergonomics 

3.4.2.1 Repetition. A repeat command, 
which reexecutes the command last exe- 
cuted, is a simple and convenient facility. 
Another alternative is to have the user ap- 
ply a new selection and then reissue the 
command. Another is to “bring back the 
last command and allow the user to edit it 
before reexecuting it. 

3.4.2.2 On-Line Documentation/ Help 
Facility. An on-line help facility is ex- 
tremely important to new and occasional 
users, as well as dedicated users who do not 
use all parts of the system regularly. The 
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help facility can provide an expanded ex- 
planation of an error message, a short sum- 
mary of a command syntax, or perhaps 
complete access to an on-line version of the 
manual. Some systems create a separate 
help window, allowing the user to have 
access simultaneously to both the help in- 
formation and to the document being ed- 
ited, rather than forcing the user to leave 
the document and lose the information 
on which the user sought help in the first 
place. 

3.4.2.3 User Feedback. Feedback is a vi- 
tal part of the editing process; it is necessary 
for specifying operations, for specifying 
scopes, and for showing the results of an 
.operation in the updated view. The last 
kind of feedback is provided out of neces- 
sity, but the first two categories are not 
always given due consideration by editor 
designers. 

In editors with typing-oriented inter- 
faces, echoing the typed command provides 
immediate feedback on both operation and 
■ scope. In function-key interfaces, a button 
push provides no inherent feedback. If no 
supplementary feedback were supplied, the 
user would have to rely on examining the 
results of the operation to see if the speci- 
fication was correct; by this time, it would 
often be too late to reverse the results. Thus 
feedback techniques, such as highlighting a 
selection in progress (with such hardware- 
supported techniques as brightening, un- 
derlining, or reverse video) in display edi- 
tors, or highlighting the menu items as they 
are browsed through in menu-oriented in- 
terfaces, are vitally important. In non-dis- 
play-oriented systems, a summary of the 
command that is to be executed or has been 
' executed is useful. This feedback might 
consist of displaying a condensed English- 
language message such as “move ‘red fox 
; v . dog’ after ‘The quick’.” If an editor has 
undo facilities, this type of condensed feed- 
back of results is useful but not necessary, 
since the user can afford to make mistakes 
or experiment. 

. Other audio and visual cues aid the user 
at a little cost in efficiency or in implemen- 
tation. Beeping to signal errors usually en- 
' sures that a user does not miss the occur- 
rence of an error. Programmable cursors 
is ik '' ■ i 
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allow the cursor to take on different sym- 
bolic forms depending upon what the user 
is doing. Time-consuming operations re- 
quire intermittent feedback so that the user 
can be satisfied that the system is still 
working. Newswhole [Tilb76] uses a Bud- 
dha icon to remind the user to be patient, 
while the Xerox Star uses an hourglass icon 
to indicate that it is busy. A status line at 
the top or at the bottom of the screen, 
indicating the current position in the doc- 
ument, the name of the file, any modes that 
might be set, and other such information, 
is an easily implemented method providing 
positive feedback. 

3.4.3 Customization 

3.4.3.1 Profiling. A profiling facility al- 
lows the user to “tune” the editor environ- 
ment at invocation time. This allows im- 
portant or preferred environment settings 
to be handled automatically and removes 
the need for all users to accept a common 
default. Some editors allow the setting of 
simple state variables such as number of 
backup versions and number of modifica- 
tions before saving the file on disk. Others 
allow each user to reconfigure major parts 
of the interface, such as redefining function 
key bindings. 

3.4.3.2 User-Defined Commands (Mac- 
ros). Editing systems often allow the user 
to define macros or editing scripts (super- 
instructions) based upon the system oper- 
ation repertoire using an editor macro lan- 
guage. The user can thus package under 
one name sequences of commands that are 
often executed as groups (see Figure 9). In 
some systems, these commands prompt for 
or simply accept parameters (operands) 
and even provide conditional execution, for 
maximum power and flexibility. Function- 
key editors often have keystroke macros; 
the system “captures” a set of keystrokes 
typed in by the user and can then repeat- 
edly execute those keystrokes as if they 
were one command. Some keystroke macro 
systems even allow the user a form of pa- 
rameterization, temporarily stopping the 
execution of the keystroke macro, allowing 
the user to type in the “parameter,” and 
then finishing the execution. 

1 
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headers. A macro to do this might look like this. 

DEFINE MACRO malUoJseaders 
deluntll /From / 
skip 2 

Insert 

next 

DEFINE MACRO END 

r::: rrrr-r 

these new underscores. 

Given, with the current line pointer pointing to a line preceedlng the line "From wcs...": 

From wes Thu Mar 5 02:49:41 1981 
To: nkm 

Subject: (un)natural language processing 
Cc: wcs 


ths Is a tst of th nw unlx* cmnd avd. It mr or Is 
blndy strps vwls frm stndd Inpt 8. pics th rslt 
on stndd otpt. 


From avd Frl Mar 6 20:17:16 1981 
To: nkm 

Subject: Another lost cause 
Cc: skf wp 

Do you know where the excess fress resource manuals are, or the master 
for that matter? Do you know how to copy It off the C-dlsk so someone 
could tako a look at It? Whero tho sourco Is kept these days? 

From skf Frl Mar 6 18:47:14 1981 
To: fac grad graphics ugrad 

Subject: The ACM Lecture Series: Judson Rosebush 

On Thu Mar 12 O 4pm In Pembroke Hall 210, the ACM will be sponsors a 
lecture by Judson Rosebush, president of Digital Effects, a NY-based 
company doing commercial computer animation, 
will be shown on film/ videotape. The talk should be 
tecessh/e Invocations of the macro ma/LtoJjeaders would result In the file being changed to: 

From wcs Thu Mar 5 02:49:41 1981 
To: nkm 

Subject: (un)natural language processing 

From avd Frl Mar 6 20: 17:16 1981 
To: nkm 

Subject: Another lost cause 


From skf Frl Mar 6 18:47:14 1981 
To: fac grad graphics' ugrad 

Subject: The ACM Lecture Series: Judson Rosebush 


Figure 9. Example of macro facility. 
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3.4.3.3 Extensibility. Some editors allow 
the user to extend the command set, in the 
same language in which the editor is writ- 
ten. Thus the user is not limited to design- 
ing macros made up of editor primitives, 
but can design operations using the same 
lowest-level primitives as the nucleus of the 
editor uses itself. The fact that the exten- 
sion is being done in an actual programming 
language, rather than a special-purpose ed- 
itor macro language, implies greater effi- 
ciency and ease of expression of new func- 
tions. In EMACS, for instance, the editor 
can be used to modify or to create a func- 
tion, and this function can be “linked” into 
the editor without ever leaving the editing 
environment. Of course, such a feature is 
not targeted to the general public but to 
more advanced users or programmers who 
are willing to learn the internals of the 
editor to modify or to add code. 

3.4.4 Target-Specific Operations 

Target-specific operations are those not 
common to all editors but specific to the 
target application area for which the editor 
is designed. A LISP program editor, for 
example, might have routines to locate 

. U# 1 '- I 


matching parentheses. The target-specific 
operations are the most marked distin- 
guishing characteristics among editors. 
These operations go further than manipu- 
lating elements simply as neutral parts of 
some larger whole; rather, they operate on 
these objects with some “knowledge” of 
what they are, for example, a capitalize 
command would need to know that 
a capital a was represented as an A. In 
syntax-directed program editors, for ex- 
ample, compilation of a syntactic entity 
is a target-specific operation. A more 
thorough description of these will be found 
in Part II in the discussion of actual 
editors. 

4. CONCLUSION: PART I 

While most editors, regardless of imple- 
mentation and configuration, offer a set of 
frequently used, “standard” editing, trav- 
eling, viewing, and display functions, there 
is a wide difference in the number of more 
specialized features, as well as in the types 
of user interface available. This diversity is 
illustrated by the collection of editors de- 
scribed in “Interactive Editing Systems: 
Part II,” which follows. 
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This article. Part II of a two-part series, surveys the state of the art of computer-based 
interactive editing systems. This paper is u survey intended for a varied audience, 
including the more experienced user and the editor-designer as well as the curious novice. 
It presents numerous examples of systems in both the academic and commercial arenas, 
covering line editors, screen editors, interactive editor/formutters, structure editors, 
syntax-directed editors, and commercial word-processing editurs. We discuss pertinent 
issues in the field, and conclude with some observations about the future of interactive 
editing. The references for both parts are provided at the end of Part II. 

Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools and 
Techniques — user interfaces; D.2.3 [Software Engineering]: Coding -prettypnnters; 
program editors ; 11.4.1 [Information Systems Applications]: Office Automation 
equipment; word processing; 1.7.0 |Text Processing]: General; 1.7.1 [Text Processing]: 
Text Editing — languages ; spelling; 1.7.2 [Text Processing]: Document Preparat.on- 
format and notation ; languages; photocomposition; I.7.m [Text Processing]. 
Miscellaneous 

General Terms: Design, Human Factors, Languages 

A .ia:,: i v„., w„r,lc Phrases: Svntnx-directed editors, structure editors 


INTRODUCTION 

Part I of this series (pp. 321-352) provides 
a reasonably comprehensive introduction 
to text editing, presenting definitions and 
an overview of the field. 

Part II presents technical details of spe- 
cific editors, using the terminology and con- 
cepts laid out in Part I. It is intended for a 
broader audience, including those quite fa- 
miliar with the concepts covered in the first 
half as well as those comfortable with the 
editors in their own computing environ- 
ments but not necessarily familiar with the 
range of editors available. This part surveys 
editors available in the academic and com- 
mercial realms, providing points of depar- 
ture for further investigation rather than 
an exhaustive point-by-point comparison. 
We discuss unresolved issues in the field, 
and examine the future of editing. The ref- 
erence list and bibliography at the end of 
Part II provide material for further reading. 


1. IMPLEMENTATIONS 

This survey discusses a wide variety of ed- 
itors used in academic and commercial cir- 
cles. Our purpose is not to provide a de- 
tailed point-by-point comparison; our cov- 
erage from editor to editor is not necessarily 
consistent in either subject matter or depth. 
Rather, using the terminology of our tuto- 
rial, “Interactive Editing Systems: Part I,” 
(pp. 321-352) we attempt to illustrate the 
capabilities outlined in Part I, Section 3, of 
that tutorial by briefly describing the dis- 
tinctive features of each editor or class of 
editors. While a taxonomy of the interactive 
editor — one in which we could compare the 
genealogy, purposes, and features of various 
systems — would be useful, it is difficult to 
construct. Terminology for categorizing ed- 
itors is far from standard, a fact that often 
leads to identical labels for less than iden- 
tical software and hardware. The history of 
editing contains many parallel develop- 
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merits and much cross-fertilization of ideas; 
a strict ordering or categorization is thus 
impossible. Informally, then, we shall be 
looking at editors from the viewpoint of the 
target applications 1 for which they were 
designed, the elements and their opera- 
tions, the nature of the interface, and the 
system configuration. These categories do 
not form strictly independent axes; the 
choice of one frequently influences the 
choice of another. 

"Target applications” are the high-level 
entities that the editor manipulates, for ex- 
ample, manuscripts, programs, or pictures. 
“Elements” are the units of target data that 
may be manipulated by the user. For ex- 
ample, a user may manipulate a program in 
the units of single lines of text, of individual 
programming language constructs, or of in- 
dividual nodes in a parse tree. User 
“operations” fall into several subcategories. 
Editing operations allow the user to manip- 
ulate the target elements. Traveling oper- 


1 In this paper, italic type is used to introduce concepts 
and terms. Sans serif type is used to set off editor 
commands. Boldface type is used for emphasis. 


at.ions allow the user to browse through a 
document. Viewing operations allow the 
user to control what subset of target data is 
presented to the user and how it is format- 
ted; lor example, text may be viewed as 
single lines, as full-screen pages, as a pret- 
typrinted program, or as a facsimile of a 
typeset document. ‘'Interface” defines the 
interaction language, input devices, and 
output devices with which the user per- 
forms these operations. “Configuration” de- 
scribes the architecture of the systems on 
which the editor can run. 

For compatibility with popular terminol- 
ogy, we review some of the most common 
terms that are used in this section. A text 
editor is one of the basic components of a 
text-processing system, which is concerned 
not only with creation and maintenance but 
also with formatting and interactive presen- 
tation of text. In addition to a text editor, 
a text-processing system includes a text for- 
matter, concerned with the layout and ty- 
pography of the text, and various text util- 
ities such as spelling correctors that aid in 
analyzing and preparing the text. Word 
processing is a commercial synonym for 
text processing. An office automation sys- 
tem typically combines a word-processing 
system with utilities such as database man- 
agement, information retrieval, electronic 
mail, and calendar management. Program 
editors operate on programs, whether rep- 
resented in textual form or in another can- 
onical form, such as a parse tree or an 
abstract syntax tree. Picture or graphics 
editors facilitate the creation and revision 
of computer-based graphics. A new devel- 
opment in the text-processing field is the 
document preparation system, which inte- 
grates text editing, picture editing, and for- 
matting. A voice editor is a specialized in- 
teractive editor in which the target is digi- 
tally encoded voice. A forms editor is an 
interactive editor that allows users to create 
and to fill in business forms conveniently. 
An interactive editor /formatter, often 
called a “what-you-see-is-what-you-get” 
editor/formatter, allows the user to edit a 
facsimile of the printed page such that the 
changed text is reformatted instantane- 
ously. On standard alphanumeric terminals, 
the facsimile represents a monospaced, 
typewriter page. On high-resolution raster 


graphics displays, the facsimile represents 
a proportionally spaced, typeset page, with 
a variety of typefaces, sizes, and weights, 
and such nontextual material as equations, 
line drawings, and even photographs. 1 he 
j goal of the universal or virtual editor, a 
current topic of research, is to generalize 
s and integrate previously target-dependent 
software, providing a uniform way to ma- 
nipulate seemingly dissimilar targets such 
as manuscript text, program text, pictures, 
i and digitized voice. A structure editor is a 
special type of virtual editor that, gains its 
l generality by imposing the same structure 
on different targets. For example, a struc- 
ture editor based on hierarchy may allow 
| the user to impose this tree structure on 
diverse targets and edit them with the same 
tree-editing primitives (e.g., delete subtree, 
move current subtree up 1 level, display all 
siblings of node). A syntax-directed editor 
is based on the same principles as a struc- 
ture editor but imposes the syntactic struc- 
ture of a particular language, rather than a 
general-purpose structure, on the target. 

1.1 Line-Oriented Editors 
Line-oriented editors are covered here sim- 
ply to round out our treatment of common 
editors. We do not, however, advocate the 
continued production or use of these edi- 
tors. The conceptual model presented with 
line editors is that of editing virtual card 
images; the line editor constantly visits the 
limitations of this outdated representation 
of data on the user. Notable drawbacks are 
pattern searches and edits that do not cross 
line boundaries, and overflow and subse- 
quent truncation of fixed-length lines. The 
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continued dependence on the card analogy 
illustrates an important design flaw in 
many editors: they adhere to outmoded 
conventions even though those conventions 
unnecessarily limit the technology of the 
day. Unlike the TECO stream model below, 
wliere lines are simply an optional filtering 
presented to the user as a service, line edi- 
tors force this limited view on the user. 

7.7.1 IBM's CMS Editor 
IBM's CMS editor (ca. 1967) is a classic 
example of a fixed-length line-oriented ed- 
itor with a textual interface, designed for a 
time-sharing system in which terminals 
lack cursor motion keys and function keys. 
It presents the user with a one-line editing 
buffer (the amount of the document that 
can be edited at a given time), although this 
is extended for some operations. Similarly, 
it presents a corresponding one-line viewing 
buffer (the amount of the document that is 
used to construct the display). The display 
is a simple mapping of the one-line viewing 
buffer to a one-line window; it is typically 
updated after the execution of each com- 
mand. (A more thorough explanation of the 
editing buffer, viewing buffer, and window 
model is presented in Part I, Section 1.) 
Traveling is done with line granularity, us- 
ing absolute and relative gotos to varying 
internal line numbers and using context 
pattern matching. The input language is 
textual with two major modes; input and 
edit mode. Typically the user spends most 
time in edit mode, with input mode re- 
served for bulk input of text. The prefix 
syntax is generally consistent across com- 
mands: 


command /scope /optional destination/optional parameters 

rhe commands are full English words; the user does not have to remember abbreviations, 
ll though the system will accept the smallest possible unambiguous abbreviation. Most 
’ommands operate on the line units, and within lines as well, if so specified by the scope. 

We now show some simple editing using the CMS editor. Assume that we are m c 
node and that the following section of a program, which computes the sum of two 
Matrices, is to be modified to compute the difference of the two matrices: 

ADD: PROCEDURE; 

FOR ROW = 1 TO N DO; 

FOR COLUMN = 1 TO M DO; 

C(ROW, COLUMN) = AtROW, COLUMN) + B(ROW, COLUMN); 

END: 
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The following sequence of interactions with the editor would provide the necessary 
changes (the user’s requests are preceded by the system prompt character 

>find/add: 

ADD: PROCEDURE; 

>change/add/subtract 
SUBTRACT; PROCEDURE; 

>next 3 

C(ROW, COLUMN) - A(ROW, COLUMN) + B(ROW, COLUMN); 

>change/+/- 

C(ROW, COLUMN) = A(ROW, COLUMN) - B(ROW, COLUMN); 
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Command 

Page 

Form 

Arguments 


2-27 

A 

[range] 

Copy 1 

2-40 

C 

position [=file-spec] .range [ .increment 1 (.incremental | 
position=file-spec/C 


2-43 

D 

[range) 

End 

2-44 

1: 

[B] [01 [S] [T] [Tile-spec] 

Overwrite input file 


Ell 


No output file 


EQ 


Strip line numbers 


ES 


No numbers, no pages 

Find 1 

2-46 

ET 

F 

1 fstrinftlC i* 7 )[range] ] (,A] [,N] (,E] [,n) [,- ] 

Help 

Input 4 

2-51 

2-52 

11 

1 

In) 

[position] [.increment] 

[posilionj ['.increment] 

[position] ];!n] 



2-55 

J 

(position] 

Kill page mark 

List:LP or Ole 

2-56 

2-57 

K 

L 

/page 

[range], S] (,P[: file -spec] ] ] 



(range] (,(S] (.1: file-spec) ] 


2-58 

M 

[position] 


2-59 

N 

[increment] [.[range] [.start] ] 


2-61 

P 

(range | [,S[ 

Replace 4 

2-63 

R 

[range] [.increment] 

[range] [.increment] 




[range] [;!n] 


2-65 

s 

I[oldstringC7sT)ncwstring] ( tsc ) [range] [,D] l.N] 


2-69 

T 

position, rangej.increment 1 [,increment2] ] 


2-73 

W 

[B] [: file-spec [ 

eXtend 6 

2-74 

X 

[range) [,N] 

Move Position 

2-76 


position 


2-77 

= 

parameter 

Set Parameter 

2-78 

/ 

parameter[:n] 

Command File 

Print next line 

2-79 

@ 

( «» ) 

file-spec 

Print previous line 


C«D 



1 Enter Alter mode. 

’Enter Copy-file mode (if 1C). 
’Enter Alter mode (if ,A). 


’Enter Decide mode (if ,D). 
‘Enter Alterdnsert mode. 


Figure 1 . SOS commands. (From Dict78. Copyright 1978 Digital Equipment Corporation. All rights reserved. 


>top 

>change/add/subtract/ • • 

Mi 1' ■ 

The routine ADD is first located by using 
the column-dependent find command that 
searches for the string “ADD:” beginning in 
the first position of a line. (The locate com- 
mands, after searching for a pattern that 
does not exist, travel to and leave the buffer 
either at the beginning or end of the file, 
frustrating the user who has erroneously 
specified a search pattern and must man- 
ually grope back to the former location.) 
The current line pointer now points to the 
line “ADD; PROCEDURE”; this line is 
echoed on the screen. The next user 
command, change/add/subtract, affects 
only the contents of the buffer: the first 
occurrence of “ADD” is replaced by 
“SUBTRACT.” For appropriate types of 
files, the editor does automatic lowercase 
to uppercase translation. If the maximum 
line length of 132 characters is exceeded, 
the editor will truncate the line. Line num- 
bers in the CMS editor are varying. Travel 
is specified relatively with next (next 3 
moves the current pointer and hence the 
editing and viewing buffers three lines down 
from the current location), or absolutely 
with goto (goto 276 moves the current 
pointer to the 276th line of the document). 
The change/ +/— command changes the 
“+” to a"—". The top command moves 
the current line pointer to the first line of 
the file. The “* *” operand of the final 
change. specifies the replacement of all oc- 
currences of “ADD” in all lines — this is a 
global change that will affect the entire file. 

The CMS editor provides the ability to 
set up logical tab stops — tabs implemented 
in the editor software rather than in ter- 
minal hardware — so that tabs may be spec- 
ified by typing a user-chosen logical tab 
character in the input stream. Certain in- 


stallation-specific enhancements of the 
basic CMS editor allow the user to undo 
the most recent command, shorten the 
scope specification by using ellipses (. . .), 
and do automatic indentation tailored to 
language-dependent needs [Brow81J. 

One of the most confusing attributes of 
the CMS editor are its two modes. Edit 
mode gives the user access to all the func- 
tional capabilities of the editor, including 
the capability to switch to input mode. In- 
put mode, however, only gives the user two 
options: typing in text, which is simply in- 
serted into the file at the current line 
pointer, or pressing dual carriage returns, 
which returns the user to edit mode. (A 
blank line is entered by typing at least one 
space.) Even if the text that the user types 
in input mode is a command, it is not exe- 
cuted. To get into input mode, the user 
types the command input while in edit 
mode (if the file is new, the user is auto- 
matically placed in input mode on invoca- 
tion of the editor). Often, a user might type 
a sequence like 

locate/bull 
next 3 
type 

only to discover, after some pondering, that 
the system is in input mode and that these 
commands were not executed but were ac- 
tually inserted into the file as text. The 
“fix” is to get into edit mode, move the 
current pointer up n lines to the first erro- 
neous line, delete n lines, move up 1 to 
reposition the pointer to the location from 
which the erroneous commands were first 
issued, and finally reissue the commands as 
commands. 


1.1.2 SOS 

SOS [Digi 78], like the CMS editor, is a line 
editor designed for editing on “glass tele- 
types” — display terminals underutilized as 
hard-copy terminal emulators— on a time- 
sharing system, specifically a wide range of 
Digital Equipment Corporation computers. 
The input language is textual and is very 
similar to the CMS editor. The commands, 
as shown in Figure 1, are typed in prefix 
notation (verb/noun). The major unit of 
manipulation is the line. 


Unlike the CMS editor, SOS attaches 
fixed, visible line numbers to each line in 
a file being edited. Typically a file is stored 
with these numbers, but special commands 
allow it to be stored without numbers and 
enable the numbers to be regenerated at 
the beginning of the next editing session. 
The editing buffer defaults to one line, al- 
though for most SOS commands a user can 
specify a line number or range of line num- 
bers to expand this editing buffer. The de- 
fault viewing buffer is a line; the window is 
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simply a mapping of this line to the output 
device. 

For selection and organization purposes, 
SOS goes one step farther and allows the 
user to create logical pages within a file, 
using the page mark command. This essen- 
tially divides the file into subfiles that are 
independently sequence numbered. SOS 
maintains a current position pointer made 
up of the current page number and the 
current line number. 

SOS is a highly modal editor, with the 
following seven different modes of opera- 
tion (see Figure 2): 

• Input mode, in which SOS accepts the 
text being typed and inserts it into the 
file; 

• Read-only mode, in which a user can 
travel through a file but not modify it; 

• Edit mode, in which the user spends 
much of the editing session performing 
editing, traveling, and viewing operations; 

• Copy-file mode, in which the user can 
copy part or all of a file into another one; 

• Alter mode, in which a user can perform 
character-by-character intraline editing 
without pressing carriage return to exe- 
cute the command; it is a textual approx- 
imation to display editing without cursor 
keys; 

• Alter/insert mode, in which the user 
can insert characters such as control 
characters that have special meaning to 
the editor; 

• Decide mode, in which the user can 
make case-by-case decisions for substi- 
tute commands. In fact, decide mode has 
two submodes, decide alter and decide 
alter/insert. These two modes differ 
from alter mode and alter/insert 
mode primarily in that they, upon re- 
turning from the submodes, leave the 
user in decide mode rather than edit 
mode. 

Alter mode is the most unusual of the 
modes. It simulates the intraline editing 
that is easily provided on display editors, 
and provides access to elements other than 
lines. The command syntax is postfix 
(noun/verb) and infix (noun/ verb/noun), 
not prefix. Commands allow the user to 
skip forward and backward by characters 
and words, delete characters and words, 


capitalize and uncapitalize characters, de- 
lete all characters until the occurrence of a 
particular character, and so on. Unfortu- 
nately, the user must explicitly enter alter 
mode to take advantage of these facilities. 

As Figure 2 shows, the transitions from 
mode to mode are almost mazelike; the user 
can easily become trapped in a remote area 
of the system. For instance, in decide al- 
ter/insert mode ESC brings one to de- 
cide alter mode, typing carriage return 
brings one to decide mode, typing CTRL- 
C brings one to edit mode, anti typing 
CTRL-Y brings one to DCL, the operating 
system command interpreter. In decide al- 
ter mode, these command bindings 
change. While CTRL-C and CTRL-Y remain 
the same, now carriage return and linefeed 
bring the user to decide mode, and both I 
and R bring the user to decide alter /in- 
sert mode. In decide mode CTRL-C and 
CTRL-Y still perform the same, but E, Q, 
and G also bring the user to edit mode. 
This time A, as opposed to ESC, will bring 
the user to decide alter mode. The re- 
maining transitions, as shown in Figure 2, 
are no less inconsistent and confusing. 

Not only are the mode transitions diffi- 
cult, but the actual command mnemonics 
for similar commands differ substantially 
from mode to mode. For example, in edit 
mode, the f (find) command allows the user 
to search for and move the editing buffer to 
the first line that contains a specified pat- 
tern; the s (substitute) command allows the 
user to replace an occurrence of an old 
pattern with a newly specified pattern. In 
alter mode the s now stands for skip and 
allows the user to find the next occurrence 
of a specified character; c (change) allows 
the user to change the next n characters in 
the line; f no longer exists. 

SOS has some interesting concepts: pow- 
erful scope specification as a suffix to com- 
mands; a regular-expression pattern- 
searching facility, as shown in Figure 3; a 
query-replace user dialogue set up by de- 
cide mode; user-selectable toggles to indi- 
cate the level of experience of the user and 
to control the verbosity of prompts; and 
more. Yet the sheer complexity of the user 
interface often makes the system undesir- 
able for even the most dedicated of users. 

We feel that SOS is a classic example of a 

1 
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represen- 
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Meaning 



Find-string constructs: 



?/ 

(ctrl/t) 

Match 

any character 


7: 

1 

Match 

any separator 


?< 

(jTKL ) 

Match 

a space or tab 


?%x 

(ctrl/e) 

Match 

any character except x 


?)x 

(ctrl/n) 

Match 

0 or more of the character 

X 

?Ix 

(CTRUV) 

Match 

1 or more of the character 

X 

79 

(CTRL/x) 

Match 

any alphanumeric character 


?! 

(ctri/a) 

Match 

any letter (A-Z, a-z) 


?& 

(ctrl/f) 

Match 

any uppercase letter (A-Z) 


72 

(CTRL, 1 *) 

Match 

any lowercase letter (a-z) 


7 + 

(CTRL/T) 

Match 

any decimal digit (0-9) 


?> 

fCIfcL/| j 

Match 

beginning or end of line 


?7c 

(CTRL/“) 

Match 

internal representation of 

c 

Substitute-string 

constructs: 


?" 

(ctrl/h) 

Substitute next string matched 


?*n?* 

(CTRL/q) 

Substitute nth string matched 



Figure 3. SOS regular expression metanotation. (From Digi78. Copyright 1978 Digital Equipment Corpora- 
tion. All rights reserved. Reprinted with permission.) 


bers in the form starting, ending as an op- 
tional prefix to each command. Thus, to 
perform the above change from add to sub- 
tract on the first 50 lines of a file, we use 
the ed substitute command: 

1 ,50s/add/subtract/ with which to form regular expressions 

. specifying the content of the pattern. The 

The special metacharacter $ indicates «,» j s ^j le K) e ene star. Thus a character “n” 
the last line of the file. Thus prepending a followed by a tells the editor to match 
1 , $ to a command causes the buffer for first character string containing a zero 

that command to be the entire file. To or more occurrences of “n". The “$” meta- 
move a number of lines, we simply say character in this use matches the end of the 

1 ,1 Om/insert after this/ hne, while the “‘" caret companion matches 

the beginning of the line. A . matches any 
This will move lines 1 through 10 to follow character. The “\” escape character allows 
the first line in the document that contains one of the metacharacters to be used as an 

the string “insert after this”. Lines in ed are actual character. Finally, the “[ ]” pair al- 

of variable length so that truncation prob- lows the user to specify a range of charac- 

lems are solved. ters to be matched: [a-j] would match the 

A powerful feature of ed is its facility for first string (a single character) containing 

user-specified regular expressions in pat- one of the letters lowercase “a” through 
terns defining the scopes of operations (as lowercase “j”; [nkm] would match the first 
opposed to other editors, which use regular string with either an n or a k or an m. If the 
expressions simply for search commands), user wanted to find the first line beginning 

(This feature has been available since NLS, with a capital letter followed by a vowel in 


but has become more common in other 
editors since its implementation in ed and 
SOS.) The user is supplied with the meta- 
characters 
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the text of the Ogden Nash poem 

I think that I shall never see 
A billboard lovely as a tree 
Perhaps unless the billboards fall, 

I'll never see a tree at all. 

the user would specify the search (using / 
as the find command) 

/'[A-Z](aeiou]/ 

The ' requires the pattern to he matched to 
start at the beginning of the line; the [A-Z] 
requires the first character of the pattern 
to be matched to be a capital letter; the 
[aeioul requires the next character of the 
pattern to be matched to be a lowercase 
vowel Upon executing this command Irom 
the top of the file, ed would find (and move 
the current pointer to) 

Perhaps unless the billboards fall, 

One interesting feature in ed is the ability 
to reference the scope of an operation in- 
directly in another operand of that opera- 
tion. For instance, to parenthesize the en- 
tire line above, one would type 

s/.*/(&)/ 

fpj le i s metanotation that means 

“match all characters on the current line. 
The is metanotation that is shorthand 
for “all that were matched.” 

As in the CMS editor, lines in ed have 
varying internal numbers. Thus traveling is 
done as in the CMS editor, with both ab- 
solute and relative specifications and with 
context pattern specification as well. A 
time-saving feature is the use of a simple 
carriage return in edit mode (with nothing 
else on that line) as an implicit next 1 
command. The user is given an explicit 
symbol called the dot to reference the cur- 
rent line pointer that can be used in arith- 
metic expressions to change the scope of an 
operation. For example, 

,-10,.+7p 

tells ed to print the 10 lines before the 
current position, the line at the current 
position, and the 7 lines after the current 
position, ed also aUows the user to mark a 
specific line with a single lowercase char- 
acter for later reference. The user simply 
types the save position command (abbre- 
viated k) followed by a single character 
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label, as in 


and the current line is now referenced with 
“x”. To travel to that line, the user simply 
types the goto saved-position com- 
mand, followed by the label 

‘x 

and immediately is returned to that saved 
position. Like the CMS editor, ed has two 
main modes, edit mode and append mode, 
and the associated problems of two modes. 

In fact, these problems are compounded by 
the fact that ed is, as characterized by 
Norman, “shy”: 

Ed's major property is his shyness; he doesn't like to 
talk. You invoke Ed by saying, reasonably enough, 
“ed " The result is silence: no response, no prompt, no 
message, just silence. Novices are never sure what thut 
silence means. Ed would be a bit more likeable if he 
answered “thank you, here 1 am,” or at least produced 
a prompt character, but in UNIX, silence is golden. 
No response means that everything is okay; if some- 
thing had gone wrong, it would have told you. 
[Norm 81, p. 144. Reprinted with permission of Data- 
mation® magazine, ©copyright by technical pub- 
lishing COMPANY, a DUN & BRADSTREET COMPANY 
(1981), all rights reserved.) 

In the edit/append mode dichotomy, this 
silence causes major confusion. To add text 
to the file, the user issues the "a” command 
to append, followed by a carriage return. 
Unlike the CMS editor, ed gives no indica- 
tion that it is now in append mode; it just 
waits for the user to input text, like the 
CMS editor. To return to edit mode, the 
user types a line with only a on it and 
follows it with a carriage return. As Norman 
points out, this is not an oversight, but in 
fact is acknowledged, rather flippantly, in 
the documentation: 

Even experienced users forget that terminating . 
sometimes. If ed seems to be ignoring you, type an 
extra line with just on it. You may then find 
you’ve added some garbage lines to your text, which 
you'll have to take out later. [KERN78a, p. 2] 

One of the designers of UNK syste m 
software defends the terseness of UNIX 
commands by citing their contribution to 
an important capability of UNIX: the abil- 
ity to easily use the output of one program 
as the input to another [Lesk81], But si- 
lencing a user-oriented interactive program 
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so that its output may be used by another 
program seems to us a large price to pay. 
In fact, UNIX easily allows the user to 
select just which output should be passed 
on to another program as standard input; 
careful programming can ensure that user 
prompts and status information can be in- 
terspersed with standard output wilhout 
interfering with it. 

While ed is a powerful line editor, it is 
questionable whether the interface, which 
requires the user to memorize small, non- 
mnemonic, and often obscure command 
names and, more critically, to “guess” the 
status of the system, is proper for a general- 
purpose audience. In fact, this editor was 
developed not for a large community, but 
for a group of a half-dozen computer science 
researchers familiar with the notions of reg- 
ular expressions and file organization who 
were designing the operating system and 
file system in which the editor would run; 
they wanted maximum keystroke efficiency 
and minimum distraction. While the ed line 
editor has illuminated several important 
concepts in editing, it nevertheless repre- 
sents a decreasingly popular breed of edi- 
tors. 

1.2 Stream Editors 

Stream editors act upon a document as a 
single, continuous chain of characters, as if 
the entire document were a single, indefi- 
nitely long character string, rather than act 
upon fixed-length or variable-length lines. 
By doing so, they avoid line editor problems 
such as truncation and inability to perform 
interline searching or editing. TECO, de- 
scribed below, is the most popular editor of 
this category. 

1,2.1 TECO 

TECO, the Text Editor and Corrector (ca. 
1970), is an interpreter for a string process- 
ing language. TECO can be used interac- 
tively as a stream-oriented editor; its basic 
commands can also be used as building 
blocks to provide quite elaborate editing 
operations. Many variations exist (DEC 
TECO and TENEX TECO are two), with 
varying capabilities and syntax. The con- 
ceptual model considers a document to be 
a sequence of characters, possibly broken 
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into variable-length virtual pages by form- 
feed characters, and into virtual lines by 
line-end characters. Pages may be com- 
bined in an in-core editing buffer consid- 
ered to be simply a varying-length string 
whose length may grow up to the in-core 
memory available. 

The interface is based on typed input, 
typically consisting of single-character 
command syntax of the form 

[argument] [single character command] 

Commands can be combined to form se- 
quences. Regardless of whether the user 
specifies a single or combined command, 
TECO does not interpret the command 
string until the user presses the ESC key. 
In the ensuing examples, the terminating 
ESC is implied. The editing buffer is the 
amount of the file in memory. The viewing 
buffer on the document defaults to the null 
viewing buffer. The document is displayed 
only upon explicit command; the user can 
specify a viewing buffer of any size, as ex- 
plained below. 

TECO maintains the current position as 
a value called point (symbolized by 
which simply contains the number of char- 
acters in the buffer to the left of it. This 
pointer can be positioned absolutely (by a 
numeric value), relatively (by a positive or 
negative character or line displacement), or 
by pattern searches. For example, in TE- 
NEX TECO [BBN73], 0J or BJ jumps the 
pointer to the top of the buffer, ZJ jumps 
the pointer to the end of the buffer, 43J 
jumps to the 43rd character of the buffer, 

. — 9 or — 9C moves the pointer backward 
nine characters, and 17;BJ jumps to the 
top of page 17. The symbols Z, B, and . are 
not simply command modifiers but are reg- 
isters that contain the point for the end of 
the buffer, the point for the beginning of 
the buffer, and the current point, respec- 
tively; thus the above commands using 
these registers resolve to an absolute char- 
acter address. 

Although TECO is character oriented, 
special commands allow the user to edit a 
document in terms of a line model. Again, 
using appropriate register values, L moves 
the pointer to the beginning of the next 
line, - L moves the pointer to the beginning 
of the previous line, 0L moves the pointer 


to the beginning of the current line. Simi- 
larly, :L moves to the end of the current 
line, while — :L moves to the end of the 
previous line. Line-oriented printing com- 
mands are provided as well; 7T prints the 
characters from the pointer until the begin- 
ning of the seventh line after the pointer, T 
prints the segment of the current line alter 
the pointer. We stress that lines are an 
abstraction provided to the user; the text is 
stored not as lines, but simply as sequences 
of characters that are interpreted as lines 
by a filter that understands special line-end 
delimiters. A more complicated filter, for 
instance, might be able to extract program- 
ming language constructs from the stream. 

Fundamental commands such as insert, 
delete and context search are supplied. 
INow is the time(CTRL-D) inserts the string 
“Now is the time” before the current 
pointer. 5D deletes the five characters after 
the pointer. Sgood(CTRL-D) finds the first 
match for “good" after the current pointer 
and moves the pointer there; similarly, 
Rgood(CTRL-D)bad(CTRL-D) replaces the 
first occurrence of “good” with “bad. 

Importantly, TECO also supports com- 
mands for conditional execution to aid in 
creating more complex commands. Q-reg- 
isters are available for holding any numeric 
or string value. Simple uses include per- 
forming arithmetic and moving or copying 
strings. To move a string of text, for exam- 
ple, the string is first saved in a Q-register 
and then deleted from the buffer (in some 
versions, the deletion is automatic). Next, 
the character pointer is moved to a new 
location and the contents of the Q-register 
are copied into the buffer at this new point. 

If a Q-register contains text, the text may 
be interpreted as a command string. Thus, 
TECO can be used as a programming lan- 
guage to build editing commands. Higher 
level commands are created by joining to- 
gether many lower level operations. Con- 
sider the pseudocode for a global change 
operation with query and replace prompt- 
ing; 

WHILE (pattern is found in source) 

IF user response = "Y" THEN 
substitute newstring for pattern 

END 

With this pseudocode in mind, to query and 
replace “good” with “bad,” one could write 


the TECO code 

J ( Sgood(CTRL-D) ;VtT-TtY’ E-4C 
Rgood(CTRL-D)bad(CTRL-D)' > 

J puts the pointer at the beginning of the 
buffer. The < > pair are loop delimiters, 
indicating that the commands inside the 
loop should be executed repeatedly. 
Sgood(CRTL-D) is the search command 
that we have seen previously. Upon failure 
of the search, ; V skips to the end of the 
loop construct. The |T is a “variable” that 
is assigned the value of a character typed 
by the user, while the TTY is the value of 
a capital Y. The subtraction expression, 
|T-j jY, equals zero only when a Y is typed 
in. Thus, if the preceding expression is 
equal to zero, then the commands follow- 
ing the E are run; otherwise everything 
until a delimiting ' is skipped. The -4C 
moves the pointer to just before the begin- 
ning of good. Finally, the Rgood(CTRL- 
D)bad(CTRL-D) performs the appropriate 
replacement. The loop then repeats until 
failure. 

The raw power of TECO is evident from 
the above example. The abstraction of text 
(a continuous stream of text with a pointer) 
is simple, especially for the programmer, as 
it parallels the abstraction ol computer 
memory with associated program counter. 
Continuing this analogy, TECO is to a text 
stream what assembly language is to se- 
quential computer memory. The TECO 
language provides a powerful base for a 
trained systems programmer or for a com- 
piler’s code generator; however, it does not 
provide a reasonable high-level interface 
for the average user, just as assembly lan- 
guage does not provide a reasonable inter- 
face for the casual (and even proficient) 
programmer. The syntax is cryptic. While 
all commands operate at the point, user 
misconceptions of the exact point location 
often result in off-by-one errors. T ECO has 
been used effectively as an implementation 
language in several editors, most notably in 
EMACS, described below. However, we be- 
lieve that it is not a proper tool for either 
knowledge workers or competent program- 
mers because of its low-level orientation. 

1 .3 Display Editors 

This category includes several editors 
based on work done by Deutsch [Deut67] 
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and on the work of Irons and Djorup 
[Ikon72], as well as several editors with an 
Irons-like model. The simple Irons outline 
for a CRT editing system has been the 
backbone of many editors: NED [Bilo77, 
Keul77], bb [Reis81], PEN [Bara81], Z 
[Wood81], and sds [Fras81], We present a 
general overview of the standard functions 
available in this kind of editor and then 
describe in more detail the unique features 
of several specific instances. 2 

In the Irons conceptual model, text is 
conceived of as a quarter-plane extending 
indefinitely in width and length, with the 
topmost, leftmost character the origin of 
the file. The user travels through this plane 
by using cursor keys and changes charac- 
ters by overtyping. At any time, the user 
sees an accurate portrayal of the portion of 
the file displayed. Text is input on the 
screen at the position of the cursor. The 
environment is "modeless”; since all typing 
on the screen is considered text, commands 
must be entered either through function 
keys, control characters, and escape se- 
quences, or by moving the cursor to and 
typing in a special command line at the 
bottom of the screen. 

The command syntax is typically single- 
operand postfix. Basic traveling and editing 
primitives are provided, such as +/- 
pages, +/— lines, +/- words, insert char- 
acter, delete word, and back word. Some of 
these may be preceded by an optional mod- 
ifier. Thus, + page scrolls forward to the 
next page, while 3 + page scrolls three 
pages. Additionally, the editing and viewing 
buffers can be moved left and right and 
, , multiple windows support easy interfile ed- 
iting. These editors make use of pick and 
delete buffers; hence deleted text is not 
discarded but is put in a buffer for possible 
subsequent use for moving or copying text. 
Functions such as delete, pick, and put may 
be combined with element modifiers such 
as character, word, line, and paragraph to 
allow more familiar specification of deletes, 
copies, and moves. A marking facility al- 
lows the user to select with the cursor two 
arbitrary points in the text to define a 


’ In this general overview, the syntax used does not 
reflect that of any given system, nor does an example 
of a general operation imply that each system contains 
that operation. 

s. - 
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scope not easily specified with the element 
modifiers. 

For display, most of the Irons derivatives 
use special algorithms to minimize the 
amount of screen updating necessary. 

1.3.1 Brown's bb 

Brown’s bb [Reis8I] is a typical example 
of the Irons model editor. Running under 
the UNIX operating system on a VAX 11/ 
780, it makes use of a wide range of function 
keys for interaction. 

One of bb ’ s extensions of the model is the 
maintenance of an up-to-date temporary 
file on disk along with a linked list of 
changes that have been made to the old 
file. This change history serves as the back- 
bone of the undo command, which is ca- 
pable of reverting changes back to the be- 
ginning of the editing session. 

For travel, as well as providing the stand- 
ard + /— keys, bb allows the user to save 
positions in named buffers and to jump to 
these positions with a goto command. 

bb provides user manipulation of the in- 
structions with the do facility. Rather than 
providing a macro language, do provides a 
mechanism for capturing and naming a 
group of keystrokes. In general, a program- 
ming-by-example facility is an extremely 
elegant, powerful tool for both the novice 
and the experienced user. The user does 
not have to think in terms of a macro 
language syntax (with associated variables, 
flow-of-control constructs, and textual ver- 
bosity), but defines the new operations in 
terms of the same syntax that is used for 
editing. Complex operations that are hard 
to specify in a procedural macro are almost 
trivial in terms of keystroke macros, where 
the user simply executes the commands 
while the system captures them. For ex- 
ample, to find all instances of a troff/me 
italic formatting command — a separate line 
of the form 

.i “this will be italicized" 

— and change them to the TgX form 

(\sl this will be italicized) 

one could use the following keystroke 
macro (all capitalized words are commands 
implemented as function keys or control 


sequences): 

-j'Qp (goes to top ot file] 

DOBEG (begins capturing keystrokes] 

ENTER ‘.i + REG-EXPR-SEARCH 

[search forward for an 
occurrence of “.i” which starts oil a new line] 
jy s l [type over existing “ i ] 

INSERT-SPACE [inserts needed space] 

+ EOL [goes to end of line, 1 character past the 

quote] 

BACKSPACE [put cursor at end quote] 

[types right bracket over quote] 
DOEND [finishes capturing keystrokes] 

Now every time the user presses the DO 
key, bb will perform all the keystrokes en- 
tered between the DOBEG and DOEND 
keys, bb does not support parameterized 
keystroke macros or macros that prompt 
for particular input and subsequently con- 
tinue executing; hence one could not design 
a general-purpose keystroke macro similar 
to the special-purpose one above. 

bb examines the file extension (file type) 
of the current file and loads an internal 
table with target-dependent information. 
This allows bb to perform automatic in- 
denting for various programming languages 
and to recognize structural entities such as 
paragraphs in documents. Like many ot the 
editors in this category, bb supports multi- 
pie viewing buffers and windows, although 
it only maintains a single editing buffer. 

bb allows users to bind their own personal 
keyboards to the standard commands by 
modifying a control file, bb also supports an 
invocation time profile, allowing personal- 
ized defaults on startup. This is coupled 
with a state-save facility that maintains 
necessary parameters from session to ses- 
sion. A help facility allows easy access to a 
complete online manual. Screen manipula- 
tion is performed by looking up terminal 
capabilities in the UNIX termcap database 
[Joy 81] to determine output device char- 
acteristics, and by using specialized screen- 
optimization algorithms. 

1.3.2 Yale's Z Editor 

Yale’s Z editor [Wood81] extends the gen- 
eral Irons functionality by providing facili- 
ties that aid in program creation while 
maintaining the general-purpose function- 
ality of the editor. 

Editor commands are entered using con- 


trol characters coupled with the cursor 
keys. Function keys are not used; the de- 
velopers dislike the fact that the user’s hand 
must be moved from the typewriter key- 
board to use them. Software allows over- 
loading of the standard ASCII character set 
by using certain keys as shift keys. The 
interaction language also supports the over- 
loading of each editor command. Here, as 
in most of the Irons derivatives, one com- 
mand may he made to do slightly diilerent 
things by prefacing it with optional argu- 
ments. For example, 
arg string fSearch 

searches forward for the next instance of 
the pattern string and moves the cursor 
there if successful. Each command may he 
prefixed with the special command meta, 
slightly altering the function of the com- 
mand to which it is attached. For instance, 
meta ISearch causes case-insensitive 
searching. 

For travel, Z remembers the last seven 
buffer positions, allowing the user to review 
previous contexts while the current one re- 
tains the status quo. Like bb, Z allows the 
user to put a “bookmark” on a certain spot 
in the file for later return. 

The unique features of Z are its solutions 
to the program-editing task. Rather than 
using the structure-oriented approach, in 
which the editor has specific knowledge of 
the syntax (and possibly the semantics) of 
a target-programming language, the Z edi- 
tor represents programs as text, offeting 
visual cues and a tight interface with exist- 
ing compilers and debuggers to take the 
place of the innate knowledge of syntax- 
directed editors. , , 

The designers of Z contend that ‘existing 
structure-oriented program editors have 
several disadvantages, such as increased 
complexity in the implementation, a restric- 
tive user interface, and poor support for 
editing” [Wood81, p. 4], Their solution is 
to represent the program as a text while 
equipping the editor with knowledge of pro- 
gram elements such as quoted strings, end- 
of-line delimiters, and matching tokens 
(such as begin/end) that signal indenta- 
tion, as well as with indentation rules. 

This representation allows Z to perform 
many functions normally associated with 
structure editors. Prettyprinting for block- 
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structured languages is done by examining 
the last token on a line when the newline 
key is pressed. If that token is in a table 
that lists it as a token requiring subsequent 
indentation or exdentation relative to the 
previous line, the next line will be appro- 
priately indented or exdented. This algo- 
rithm gives the desired result most of the 
time; a manual mode is offered to correct 
any mistakes made by the automatic mode. 
The matching token table also drives com- 
mands that close off the most recently be- 
gun matching unit, that find the end of the 
nearest unit if already closed, and that skip 
over the matching expressions as single 
units. This is particularly useful in LISP 
programming, where levels of parenthesi- 
zation are hard to manipulate. Again, this 
facility does not require the editor to have 
syntactic knowledge of the target language, 
but simply to maintain a table of matching 
tokens. 

Syntax-directed structure editors allow 
the user to manipulate syntactic units as 
single entities, as well as to view levels of 
syntactic detail. Z provides analogous fea- 
tures based on indentation level, which the 
designers claim work because “all the im- 
portant information about the block struc- 
ture of a program is contained in the inden- 
tation, provided the programmer is consis- 
tent” [Wood81, p. 5], 

The designers of Z chose to do neither 
the syntactic checking nor the incremental 
compilation often associated with syntax- 
directed editors, as the philosophy is not to 
integrate the compiler directly into the ed- 
itor. Feeling that, “the programmer is the 
person best able to decide when his pro- 
gram is in a state ready for compilation” 
and that “existing compilers are perfectly 
able to locate errors” [Wood81], the de- 
signers of Z attempted to enhance commu- 
nications between editor and compiler. The 
user can execute the compile command 
from the editor; this communicates with an 
asynchronous process that formats the 
compiler request per the target language, 
puts the request on the processor queue, 
appends error messages in a special file, and 
returns a completion message to the editor 
when done. The user can continue editing 
while this is being done. 

Z also provides a link to Multiple User 


Forks, a program that maintains multiple 
user contexts in parallel. This allows the 
user to exit from Z into any of the other 
forks (perhaps to read documentation or 
check on the state of some running pro- 
gram) and to return to Z without loss of 
state. 

1.3.3 EMACS 

EMACS is an M.I.T. display editor de- 
signed to be “extensible, customizable, and 
self-documenting” [StalSO, Stal.81]. Sev- 
eral versions and dialects exist, most nota- 
bly the Stallman version for the Tops-20 
operating system (from which our examples 
are derived), the Honeywell Multics version 
[Gree80], and the UNIX version by James 
Gosling of Carnegie-Mellon. Some versions i 
of this full-screen editor for time-sharing 
systems are written in TECO; others are 
written in the high-level language LISP. To 
extend or customize the functionality, users 
write routines in the same language as that 
in which the standard editor functions are 
written, rather than using an editor macro 
language. Richard Stallman, the designer 
of the first EMACS, feels that this capabil- 
ity allows the user to transcend any limi- 
tations imposed by the editor’s implemen- 
tors. The basis of the successful EMACS 
strategy is that defining the extensions or 
changes in the source language “is the only 
method of extension which is practical to 
use” [Stal81, p. 147]; it is unwise to main- 
tain a “real” implementation language for 
the implementors and a “toy” one for the 
users. The user is able to bind many exten- 
sions or changes in a library, which can be 
loaded at invocation time. In fact, many of 
the core facilities that exist today were orig- 
inally user-written extensions and were 
later adopted into the production system, 
encouraging arbitrary growth rather than 
design. EMACS does offer a keystroke ma- 
cro facility with prompts, so that nonpro- 
gramming users do have an alternative to 
a programming language at their disposal. 

In EMACS, every typed character is con- 
sidered a command. The keys for printing 
characters are bound, by default, to a com- 
mand called self insert that causes that 
character to be inserted into the text at the 
cursor location. Generally, nonprinting 
characters (control and escape sequences) 
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invoke commands to modify the document. 
The editing language accepts single-char- 
acter commands and finds the current bind- 
ing between command key and function in 
a table. EMACS and other display editors 
offer a quote facility that allows characters 
typically used as commands to be inserted 
as characters into a document. A few of its 
many interesting features include a query 
replace facility, transposition functions for 
lines and words, and an automatic balanced 
parenthesis viewer. 

The windowing facilities are extensive as 
well. The system supports multiple open 
files and hence editing buffers' 1 with asso- 
ciated viewing buffers and windows. '1 he 
CTRL-X 2 command divides the screen into 
two windows containing the viewing buffers 
designated by the user. The cursor is in one 
window at a time; CTRL-X 0 switches be- 
tween windows. Special “narrowing” com- 
mands serve to change the size of the view- 
ing buffer and editing buffer while leaving 
the window intact. The user marks one end 
of a region, moves the cursor to the other 
end, and issues the command CTRL-X N. 
This range now defines the maximum range 
of the editing buffer. If it is larger than a 
window’s worth of text, the viewing buffer 
is set to a full window’s size; otherwise, it is 
set to the size of the editing buffer. 

The fact that all keys (including alpha- 
numerics) are bound to actions is very im- 
portant, as the self insert action can be 
extended to effect more complex results. 
For example, one can extend the definition 
of the space character to insert itself and to 
check to see if an automatic word wrap is 
necessary. A more detailed use of the key 
redefinition facility is the EMACS abbre- 
viation package. Here, all the punctuation 
characters are redefined to look at the pre- 
vious word, to check for its existence in an 
abbreviation table, and if it exists, to sub- 
stitute the expanded word for the abbrevi- 
ation as the user types. 

EMACS offers major modes, editing en- 
vironments tailored for editing a particular 
kind of file. For example, text mode treats 
the hyphen as a word separator; LISP 

1 Note that our use of the term “editing buffer here, 
while consistent with our previous usage, differs 
slightly from Stallman's terminology in describing 
EMACS [Stal80, Stal81]. 
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mode distinguishes between lists and s- 
expressions. The major mode can automat- 
ically define different key bindings for a 
particular application. For example, in 
many programming language major modes, 
the tab key is redefined to provide auto- 
matic indentation. 

EMACS can keep a record of all key- 
strokes typed in a session in a journal file. 

If a system crash destroys a current editing 
session, the user can instruct EMACS to 
bring up an old version of the file and replay 
the keystrokes from the journal file. I be 
user watches the changes being made, and 
can stop the process at any time. ( 1 bis 
allows a primitive undo facility: the user 
can replay up to a desired point and then 
discard the rest of the changes that are no 
longer wanted.) 

Another interesting facility for program 
editing is the TAGS package. The separate 
program TAGS builds a TAGS table con- 
taining the file name and position in that 
file in which each application program func- 
tion is defined. This table is loaded into 
EMACS; specifying the command Meta, 
function name causes EMACS to select the 
appropriate file and go to the proper func- 
tion definit ion within that file. Other special 
libraries include DIRED, a subsystem for 
editing a file system directory using the 
full-screen display capabilities, and BABYL, 
a complete message-handling subsystem. 
INFO reads tree-structured documentation 
files, performing the necessary operations 
to travel from one node to the next. 

EMACS has a very large and faithful 
following in the academic research com- 
munity. While the basic editor is not vastly 
different in functionality from the Irons 
model editors, the customized, application- 
specific packages have “sold” the system. 
To obtain a distribution of EMACS, one 
must agree to redistribute all extensions 
that one develops. By now, these extensions 
are quite numerous and powerful. Thus it 
is not the raw editor, but the editor and its 
extensions that far exceed the capabilities 
of most other editors. While the program- 
ming language certainly cannot be used 
competently by the average user, the avail- 
ability of extensibility features for program- 
mers has manifested itself in many powerful 
facilities. 

Computing Surveys, Vol. 14, No. 3, September 19S2 






368 



N. Meyrowitz and A. van Dam 

Extensibility, however, has negative 
points. Although the major new packages 
are distributed to all EMACS installations, 
many customizations are personal ones. 
This leads to situations in which two people 
using EMACS have different syntax and 
functionality. One set of keyboard bindings 
might be different from the next (e.g., one 
CTRL-D moves down one line, while an- 
other deletes a line) or, alternatively, an 
identical keyboard arrangement and appar- 
ently identical functionality may have fine 
distinctions that confuse a user from a dif- 
ferent microcosm trying to use someone 
else’s EMACS (e.g., one GOTO END-OF- 
WORD command might go to the last char- 
acter in a word, preceding punctuation, 
while another may go the first white space 
following the word). Thus with extensibility 
in any editor comes the price of widespread 
divergence over various installations and 
even over the same installation. The trade- 
off between a large number of divergent but 
customized dialects and a single, standard 
language is unclear. 

1.3.4 IBM's XEDIT 

XEDIT [IBM80] is IBM’s screen editor for 
their VM/CMS time-sharing system. Un- 
like the Irons model editors just described, 
XEDIT uses local terminal intelligence to 
perform screen-editing operations. The 
high-level conceptual model is the un- 
bounded quarter-plane of text in which the 
user views a rectangular region, yet XEDIT 
still relies on the sequential card model in 
some of its operations. 

The display editing functions of XEDIT 
only work on IBM 3270 or 3270-compatible 
terminals. These terminals have a local 
screen buffer memory and a special key- 
board with keys that support editing on the 
local buffer, such as add char, delete char, 
and delete to end of line. 

The user has several methods of com- 
mand specification. The first is changing 
the screen image by driving a cursor and 
using the local editing capabilities. The user 
is able to edit both the displayed text and 
a status line that displays file name, record 
length, and several other options. The user 
changes the text and the status line by 
simply inserting, deleting, or changing the 


options field of each line. Pressing the EN- 
TER key causes the contents of the editing 
buffer to be sent to the host computer, 
which determines the difference between 
the terminal’s local editing buffer and the 
host’s internal data structure, and updutes 
its internal data accordingly. This synchro- 
nization between the screen buffer and the 
internal data structure is an important com- 
ponent of an editor using a terminal with 
local intelligence. Note that throughout this 
editing process, the host processor is not 
signaled of any changes, regardless of how 
long the user has been editing a screenful 
of text, until the user presses the ENTER 
key to transmit that screen. 

Besides the display-editor-style com- 
mands, XEDIT accepts typed commands 
that are almost identical to those of the 
CMS line editor; in fact, on non-3270 series 
terminals, XEDIT operates essentially like 
the CMS line editor. These commands, 
typed in on a special command line, control 
those operations that cannot be done using 
the local editing buffer, including control 
functions, such as reorganizing viewing 
buffer-window mappings and ending a ses- 
sion, search commands, and some types of 
insert, move, and copy commands. Any of 
these commands can be bound to the ten 
function keys on the keyboard. XEDIT 
cannot support selection by marking with 
a cursor because the current position of the 
cursor cannot be read by the CPU. While 
it does allow textual specification of region 
commands, it also provides the user with a 
prefix field before each line on the screen 
(see Figure 4) to give additional function- 
ality. 

As we see in Figure 4a, the D on the line 
beginning “THE HIPPOPOTAMUS" marks 
this line for subsequent deletion. The 2a is 
an instruction to add two blank lines after 
this line. The DD is a grouping marker that 
delimits the beginning and end of a region 
of text to be deleted (the two DDs need not 
be on the same screen of text). The single 
A again stands for adding a blank line. 
When the user presses ENTER, the screen 
buffer is transmitted, and the host com- 
puter interprets the prefix fields (as well as 
any local editing), updates the internal data 
structure appropriately, and redisplays the 
updated text, as shown in Figure 4b. 
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ANIMALS FACTS 


A1 F 80 TRUNC=80 SIZE=1A LINE=9 COLUMNS 


* * « TOP OF FILE * * M 

THE HIPPOPOTAMUS IS DISTANTLY RELATED TO THE PIG. 

ELEPHANT TUSKS CAN NEIGH MORE THAN 300 POUNDS. 

LAND CRABS FOUND IN CUBA CAN * ° 

ELECTRIC EELS CAN DISCHARGE BURSTS OF 625 VOLTS, 

m^CIENT^OMANS AND GREEKS BELIEVED THAT BEDBUGS HAD MEDICINAL 
STURGEON^ IS^THE LARGEST^FRESHWATER^F ISH^ AND^CAN^WEIGH 2250 POUNDS. 

ants have five different NOSES. EACH ONE IS designed to ^ 



: ACCOMPLISH A DIFFERENT TASK. 

= ALL OSTRICHES ARE POLYGAMOUS. 

- SNAKES LAY EGGS WITH NOHBRITTLE SHELLS. 

= THE* PLATYPUS HAS A DUCK BILL, OTTER FUR. NEBBED FEET, LAYS 
= EGGS, AND EATS ITS OHN WEIGHT IN WORMS EVERY DAY. 

= . . . END OF FILE * « « 


XEDIT 1 FILE 


ANIMALS FACTS 


F 80 TRUNC=80 SIZE=13 LINE=9 COLUMNS 


===== « • « TOP OF FILE * * * 

===== ELEPHANT TUSKS CAN WEIGH MORE THAN 300 POUNDS. 

----- UND C RABS FOUND IN CUBA CAN RUN FASTER THAN A DEER. 
===== ELECTRIC EELS CAN DISCHARGE BURSTS OF 625 VOLTS, 
===== A0 TIMES A SECOND. 


THE ANCIENT ROMANS AND GREEKS BELIEVED THAT BEOBUGS HAD MEDICINAL 
PROPERTIES WHEN TAKEN IN A DRAFT OF WATER OR WINE. 

ALL OSTRICHES ARE POLYGAMOUS. ...- 

I...* 1 ♦ 2 ♦ 3 * ^ ♦ 5 ♦ 6 *• 

SNAKES LAY EGGS WITH NONBRITTLE SHELLS. 

THE PLATYPUS HAS A DUCK BILL, OTTER FUR, WEBBED FEET, LAYS 
EGGS, AN0 EATS ITS OWN WEIGHT IN WORMS EVERY DAY. 

* * * END OF FILE « » * 


XEDIT 1 FILE 
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Figure 5 shows a similar move command 
using the prefix fields. The mm is a grouping 
marker, much like the DD above, to delimit 
the beginning and end of a multiline region 
of text to be moved, and the f is a market- 
signaling the line after which the moved 
text should be inserted. 

XEDIT’s local editing style offers both 
advantages and disadvantages. The use of 
the local 3270-series editing capabilities im- 
plies that users need not worry about an 
overloaded host system most of the time; 
most of the intraline editing, and even some 
of the block moving, as above, can be done 
without intervention of the host CPU. The 
editor is dependent upon the host system 
only when a screenful of text must be trans- 
mitted or a textual command (like search) 
must be executed. On the other hand, the 
local buffer offers no safety; if the host 
system crashes while a user is screen edit- 
ing, all modifications on the local buffer are 
lost. More specific to XEDIT, the inability 
to do region selection within lines (because 
marking without CPU intervention is im- 
possible on the 3270) reduces the generality 
of the editor. Additionally, the several 
styles of commands (typed, cursor driven, 
prefix field) can confuse a novice user. 

j 

1.4 Graphics-Based Interactive Editor/ 
Formatters 

1.4.1 Xerox PARC's Bravo 

Xerox PARC’s Bravo (ca. 1975) is one of 
the first of the interactive editor/formatters 
based on the display of high-resolution, pro- 
portionally spaced text. Bravo allows the 
creation and revision of a document con- 
taining soft-typeset text with justification 
performed instantly by the system. The 
conceptual model is of a continuous scroll 
of typeset text that can be paginated when 
desired. 

Bravo runs on Xerox’s Alto, a 16-bit min- 
icomputer with a raster graphics “portrait” 
display (roughly 8J) X 11 aspect ratio) of 
606 X 808 pixel resolution. This high-reso- 
lution pixel-addressable display allows 
more complex visual cues (overlapping win- 
dows, typeset facsimile text, graphics) than 
does the alphanumeric CRT terminal. A 
mouse drives a cursor and offers three but- 
iiil 5 - ■ ■ ; . : . - ! 
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tons (called left, middle, and right) that can 
be read independently of the cursor. 

Bravo offers a mix of graphical and key- 
board user interfaces. By moving the 
mouse, the user drags the cursor across the 
screen. The cursor addresses characters, 
special “menu” items, and other selectable 
elements on the screen. The interaction 
language is modal: the user can be in either 
command mode, in which text elements can 
be selected and commands initiated, or typ- 
ing mode , in which keyboard text is entered 
into the document. Because of the modes, 
the user can specify commands with single 
alphanumeric characters; unlike many dis- 
play editors, alphanumeric characters are 
not entered into the document unless the 
user is in typing mode. Commands not in- 
voked with single alphanumeric keys are 
invoked with control characters. 

As shown in Figure 6, the Bravo screen 
is divided into several areas. The system 
window contains information concerning 
what the user has just done and what can 
be done at present. The document window 
contains a viewing buffer’s worth of the 
document text scroll. The line bar and 
scroll bar are graphical entities that help 
the user travel through the document. 

To travel in Bravo, the mouse is used to 
move a double-headed arrow cursor along 
the scroll bar, a vertical strip at the left side 
of the document. Pressing the left button 
on the mouse while the arrow is pointing to 
a line in the document’s window causes that 
line to become the top line in the window; 
pressing the right button causes the top line 
in the window to move to the line the cursor 
is at. For more extensive traveling, one is 
supplied with a graphical thumbnail that 
moves along the scroll bar, and a bookmark 
that indicates the approximate current po- 
sition in the document on a graphically 
displayed linear continuum from "front 
cover” to “back cover.” If the user is half- 
way through the document, for instance, 
the bookmark indicates a point halfway 
across the continuum. To travel to a part 
of the document preceding what is being 
viewed, the user simply places the thumb- 
nail somewhere before the bookmark on 
the continuum and presses the middle but- 
ton; the document will “fall open” at the 
corresponding position in the text. By plac- 
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CHAMELEONS, reptiles that live in trees, change their color when 

===== THE T gSpPY L !s A NAMED D AFTER THE REVEREND ROBERT GUPPY, WHO FOUND THE FISH 
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Tho three buttons on the mouse are called LEFT (the left-most 
one), MIDDLE (the middle one) and RIGHT (the right-most one). 

They haye different functions depending on where the cursor Is 
on the screen and what shape It has. Don’t push any buttons vet 

Mouse Tore: 

: You will find that the mouse works better if you hold it so 
that It bears some of the weight of your hand. 

If the cursor doesn’t move smoothly when the mouse is 
moving, try turning the mouse upside down and spinning 
the ball in the middle with your finger until the cursor does 
move smoothly as the ball moves. If this doesn’t help, your 
mouse Is broken; get it fixed. 

2. Basic features 

; ' . 1 . . 

This section describes the minimum set of things you have to 
know in order to do any useful work, with Bravo. 

2.1 Moving around 

Move the cursor to the left edge of the screen and a little bit 
below the heavy black bar. Notice that it appears as a double- 
headed arrow. It will keep this shape as long as you stay near the 
left edge, in a region called the scroll bar. ir you move It too far 
right, the shape will change. Keep the cursor In the scroll bar for 
the moment 

Now push down the LEFT button and hold it down. Notice that 
the cursor changes to a heavy upward arrow. This indicates that 
when you let the button go, the line opposite the cursor will be 
moved to the top of the window. Try it Thls ls called scrolling 
the document up. 

.\rtHV hi ■ -C'l'jfc' j’.' . ■ : • . 

Next push down the RIGHT button and hold It down. Now the 
arrow points down, indicating that when you let the button go, 
the top line on the screen will be moved down to where the 


Figure 6. Bravo display. (Courtesy Xerox Corporation.) 
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ing the thumbnail after the bookmark on 
the continuum, the user can similarly travel 
through the remainder of the document. 

Bravo uses a postfix/infix interaction 
syntax: a selection is followed by the com- 
mand, followed by an optional argument. 
For example, deletion works by selecting 


the scope and pressing the D key, while 
insertion works by selecting the scope, 
pressing the I key, typing the desired text, 
and finally pressing the ESC key. 

Selection operates on four main ele- 
ments: characters, words, lines, and para- 
graphs. The left and middle buttons of the 


mouse are used to select items, while the 
right button is used to extend those selec- 
tions. With the cursor in tire text urea, the 
left button would cause the addressed char- 
acter to be selected as the scope, while the 
middle button would cause the addressed 
word to be selected. To select the laige 
elements, the user moves the cursor into 
the line bar. In the line bar, the left button 
selects a line and the middle button selects 
a paragraph. Extending tire selection allows 
the user to specify a scope that lies between 
two of the entities addressed. Thus, clicking 
left in the text area would cause a single 
character to be selected; clicking right at 
some other character would cause all the 
text between (and including) the two se- 
lected characters to be selected. Similarly, 
a middle right sequence would select all the 
text between and including two words. In 
the line bar, a left right sequence selects all 
the text between and including two lines; a 
middle right sequence selects all the text 
between and including two paragraphs. 

Operations are typically performed on 
the current selection. To delete a word, the 
user simply selects a word by clicking the 
middle button and then types D to execute 
the delete command. Similarly, to delete all 
the text between and including two para- 
graphs, the user clicks middle right in the 
line bar and types D. Changes are done 
analogously. To replace a word, the user 
clicks middle and types R. Bravo deletes 
the selected word and puts the user into 
insert mode; everything the user types until 
the ESC key is pressed is inserted in place 
of the old word. The Append and Insert 
commands allow the user to add text in a 
similar manner without first deleting a se- 
lection. Bravo supplies an undo facility that 
undoes only the last operation. 

Files are never saved until the user ex- 
plicitly saves them. However, Bravo keeps 
a transcript of the operations that have 
occurred in the editing session. One can run 
BravoBug with the transcript against the 
old version of the file to interactively replay 
the editing session. The user is given the 
choice of single-stepping through each 
change or running the entire transcript, 
stopping whenever desired. 

At the time of its introduction, the most 
innovative features of Bravo were its inter- 
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active formatting facilities. Bravo's unit lor 
specifying the formatting attributes of text 
is the look. Each character in the document 
has associated with it particular looks; the 
looks of any character can be displayed by 
selecting that character and typing L ? . The 
looks specify a large assortment of type 
attributes; font style, point size, subscript- 
ing, superscripting, centering, justification, 
nested indenting, and leading (interline 
spacing), to name a few, are attributes that 
the user can change by typing L, followed 
by a one-character operand. Other look at- 
tributes cannot be changed directly by com- 
mand but are constrained by previous for- 
matting attributes. As soon as a look com- 
mand is executed, the document is dynam- 
ically reformatted to effect the revision— 
the document is up-to-date in both format 
and content at all times. A special page 
format mode allows the user to see the 
document paginated as it will be printed. 

Bravo does not allow integrated graphics, 
but provides output that can be postpro- 
cessed to add pictures from the PARC in- 
teractive picture-editing systems [Baud78, 
Newm78, Bowm81]. 

1.4.2 Xerox Star 

Star [SeyJ81, Xero82, Smit82], Xerox's 
commercial successor to the Bravo, is, in 
terms of its user interface, the most ad- 
vanced commercial product for office au- 
tomation on the market at the time of this 
writing. 

Like the Alto, the 8010 work station on 
which Star runs is a personal computer 
with access to shared resources such as file- 
and printer-servers via an Ethernet net- 
work. It has a “landscape” 13} X 10} inch 
screen with a resolution of 1024 x 809 pix- 
els, capable of displaying both a full page of 
a document and a large menu area. 

Several design goals are important to the 
understanding of Star’s interface and func- 
tionality: 

• The designers determined that users 
should simply point to specify the task 
they want to invoke, rather than remem- 
ber commands and type key sequences. 
They believed that the user should not 
need to remember anything (of conse- 
quence) to use the system. 
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• An important consideration was the de- 
velopment of an orthogonal set of com- 
mands across all user domains; the copy 
command in the text formatter, for ex- 
ample, should have similar semantics to 
one in the statistical graphing package. 

• The system was designed to operate by 
"progressive disclosure.” Star strives to 
present the user with only those com- 
mand choices that are reasonable at any 
given juncture. 

• Finally, Star is an interactive editor/ 
typesetter; the screen is, for the most 
part, a facsimile of what the final docu- 
ment will look like. 

The Star development team, which 
worked several years considering possible 
models, remarks: 

The designer of a computer system can choose to 
pursue familiar analogies and metaphors or to intro- 
duce entirely now functions requiring new ap- 
proaches. Each option has advantages and disad- 
vantages. We decided to create electronic counter- 
parts to the physical objects in an office: paper, 
folders, file cabinets, mail boxes, and so on — an 
electronic metaphor for the office. We hoped this 
would make the electronic “world” seem more fa- 
miliar, less alien, and require less training. (Our 
initial experiences with users have confirmed this.) 
We further decided to make the electronic analogues 
be concrete objects. Documents would be more than 
file names on a disk; they would also be represented 
by pictures on the display screen. [From “Designing 
the Star user interface” by D. C. Smith, C.l Irby, R. 
Kimball, B. Verplank, and E. Harslem in April 1982 
issue of BYTE magazine, © 1982 Byte Publications, 
Inc. Used with permission of Byte Publications, 
Inc.] 

The high-level conceptual model of the 
environment is that of a desk top on which 
multiple documents can be manipulated si- 
multaneously. Star uses a two-button 
mouse and a postfix interaction syntax. 
Rather than presenting the user with a 
simple textual menu or list of available 
options and files, Star presents graphical 
icons that resemble the entity to which the 
user is referring (see Figure 7). 

To open a file for editing, the user simply 
points to the iconic file drawer that sym- 
bolically holds the document (noun selec- 
tion) and issues the open command (verb 
selection). Choosing open causes a file 
drawer directory, containing identifiers for 
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file folders and individual documents, to fill 
part of the screen. The user can open, copy, 
move or delete any of these folders or doc- 
uments; touching copy, for example, causes 
a new document icon to be placed on the 
user’s “desk top” area on the screen. Se- 
lecting this icon and opening it causes the 
editor to open a window that is large 
enough to hold a facsimile of an 8j x 11- 
inch page (see Figure 8). Editing operations 
similar to those provided by Bravo can be 
performed in this window. The interface, 
however, does not use control characters. 
Mouse buttons and function keys provide 
the most frequently used commands; a 
menu of window-specific commands ap- 
pears in the window banner at the top of 
the window for selecting with the cursor, 
and a menu of infrequently used system 
commands is available by selecting a menu 
icon in the upper right corner of the screen. 

Traveling buttons located on the bottom 
and right borders of each window, as shown 
in Figure 8, are selected with the mouse. 
The h- on the bottom makes sure that the 
left margin of the document is in view while 
the — I makes sure the right half of 
the document is in view. The — ► scrolls 
the document to the right, the <— scrolls 
the document to the left, the J, scrolls the 
document downward, and the f scrolls the 
document upward. P goes to the previous 
document page, while N goes to the next 
document page. 

Other icons include a printer icon, a 
floppy disk icon, and an in/out box icon. To 
print a file one simply selects the appropri- 
ate document icon and places it on top of 
the printer icon. The programmable cursor 
changes to an hourglass to indicate that 
processing is taking place. Similarly, elec- 
tronic mail is sent by placing a document 
icon on the out box and is received by 
selecting the in box. 

As in Bravo, the mouse is used to drive 
the cursor and select elements. Selections 
are performed with the left mouse button 
and can be adjusted with the right mouse 
button. To select a character in the text, 
the user clicks the left button. Subse- 
quently, when the right mouse button is 
held down, all the characters between the 
selected point and the current position of 
the cursor will be highlighted in reverse 
video; when the right button is released, the 
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figure 7. Star icons. (Courtesy Xerox Corporation.) 
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Figure 9. (a) Search operation; (b) search and replace operation. (Courtesy Xerox Corporation.) 


copy that need multiple operands are spec- 
ified in infix or prefix, as appropriate. To 
perform a find, the user presses the find 
function key and is given a find property 
sheet to fill out, as shown in Figure 9a. The 
user fills in the Search for box by typing a 
search pattern and specifies other attri- 
butes of the search by selecting various 
options on the property sheet with the 
mouse. (Here TEXT, IGNORE CASE, and 
ENTIRE DOCUMENT are selected.) The op- 
tions that are selected remain selected from 
search to search until the user explicitly 
alters them. To perform the search, the 
user selects the Start button in the window 


menu. While Star is searching, it displays 
the message “Searching . . as feedback 
for the user. The ? and Cancel button pro- 
vide help and abort the search, respectively. 

The search and replace operation uses 
the same property sheet. Picking the 
CHANGE IT button on the find property 
sheet brings into view a second set of prop- 
erties. The user can now type in the pattern 
to Change to and specify what should be 
altered and whether the replacement 
should be done with confirmation. When 
performing these operations, the message 
“Substituting ...” provides needed feed- 
back. 
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Figure 10. Character property sheets. (Courtesy Xerox Corporation.) 


Like Bravo, Star performs instant for- 
matting and justification in the proper type 
size and style. Associated with each ele- 
ment (an element being any entity from a 
character to the entire document itself) are 
property sheets that contain status infor- 
mation for that element (see Figure 10). 
Initially, attributes in property sheets have 
system-assigned default values. To change 
the typeface of a particular character, the 
user selects the character, presses the props 
key, points to the desired typeface in the 
property sheet and closes it. The change 
takes effect immediately. (Note that the 
property sheet is presented in the same 
kind of window as a normal document. In 
fact, to see all the available typefaces in 
this example, the user would have to scroll 
the document to the left with one of the 
scroll symbols.) Star enables the user to 
define a standard collection of property 
sheets to provide document templates 
(style sheets), as in a database-driven for- 
matter such as Scribe. The user simply 
copies the template and enters the new 
text, assured that the basic format is 
properly defined. The designers compare 
this to tearing off a standard form from a 
preprinted pad [Smit82], 

Star provides a drawing package, the re- 
sults of which can be integrated into a 


document (see Figure 11). The user selects 
lines, boxes, shading patterns, and other 
primitives from a menu and uses these to 
draw on a user-determined grid. Just as 
selections can be extended, several graphic 
items can be selected at once by holding 
down the appropriate mouse buttons. Users 
are also allowed to define clusters of graph- 
ical items to form new “primitives." Graph- 
ics can be scaled up or down to fit in a fixed 
space in a document. Star also provides 
packages for making and editing bar charts 
and spread sheets, and for retrieving infor- 
mation through a relational database sys- 
tem. The designers have stressed what we 
believe to be a vitally important concern: 
that all the packages have consistent inter- 
faces, as users especially want a particular 
command to behave in a consistent way in 
the provided multi view environment. 
Whether in the text editor, the graphics 
editor, or the chart maker, the user issues 
commands by selecting the object of the 
operation and issuing the appropriate com- 
mand through function keys or menu but- 
tons. To delete a word, one selects the word 
and presses the delete key; to delete a rec- 
tangle, one selects the rectangle and presses 
the delete key. 

Besides its carefully crafted user inter- 
face, Star provides some interesting solu- 
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C Demo Doi 


Productivity under the old and the new 


XEROX 

8010 Star Information System 

U*er-!nterface Detiga 

-• mike it easy to compose text and graphics, 
•V do electro nic filing printing; and mailing 
All at the rime tro rotation, requires a 
vclar.onary user-interface design. 

fir-wwp display - Each of the 827,392 dots on 
y.e screen ts mapped to a bit in memory, thus, 
arbitrarily coapiex images can be displayed. 
•STAR displays all fonts and graphics as they 
▼ill be printed. In addition, familiar office 
cfciects such as documents, folders, file 
drivers and m-baskets are portrayed as 
pnrable images. 

Th* .-toe a* - A unique pointing device that 
ilicvs die user to quickly select any text, 
graphic or office object on the display. 

See and Point 

All Star functions are visible to the user on 
the keyboard or on the screen. The user does 
Juing and retrieval by selecting them vith 
the mouse and touching the Move; COPY, 
zzittz or FBOFr*riE3 command keys. Text 
and graphics are edited *rnfa the same keys. 


Experience at Xerox vith prototype verk- 
stations has aho vn shorter production timer 
and lover costs. The folWing equities 
expresses this. 


Figure 1 1 . Star graphics. (Courtesy Xerox Corporation.) 


tions to typical online manuscript-prepa- 
ration problems. Mathematical and foreign- 
language typesetting in most systems in- 
volves using escape/control sequences or 
long English-language mnemonics to rep- 


resent the special characters. Star presents 
the virtual keyboard , a graphical represen- 
tation of the keyboard on the screen. To 
use a key, one simply points at it or presses 
the corresponding physical key. Star has 
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knowledge of mathematical symbols and 
can construct complex equations and for- 
mulas as they are typed, changing the size 
of the symbols used as equations get larger 
or smaller. Editing continually adjusts the 
horizontal and vertical spacing and place- 
ment of subscripts and superscripts. 

1.4.3 ETUDE 

ETUDE [Hamm81] is a document produc- 
tion system designed with twin goals: “to 
extend the functionality of conventional 
word processing systems while reducing 
the complexity of the user interface.” Un- 
like Bravo or Star, ETUDE uses prefix 
syntax: 

action modifier element 

where an action might be move or delete, 
a modifier might be a number or a word 
like start-of or next, and an element might 
be paragraph, word, document. The design- 
ers feel that the prefix syntax, as in “delete 
3 words,” more closely approximates nat- 
ural language, and thus is preferable. 

Like Bravo and Star, ETUDE is an in- 
teractive editor/formatter, providing type- 
set, formatted text on a stand-alone work 
station with a bit-mapped screen. ETUDE 
has adopted a Scribe-like method for de- 
scribing formatting, switching the burden 
of complex formatting from the user to a 
document database that contains standard 
formats for a range of documents and doc- 
ument components. In a letter, for example, 
the ETUDE system will do special format- 
ting for the returnaddress, address, salu- 
tation, body, and signature. While ETUDE 
always keeps the up-to-date formatted doc- 
ument on the screen, it uses the left margin 
of the screen as a format window to place 
formatting descriptor tags that indicate the 
type of high-level action that has been 
taken on a particular section of text (see 
Figure 12). This technique attempts to 
bridge the gap between the unformatted 
but explicitly expressed formatting code, 
and the displayed facsimile page that, once 
formatted, often does not contain informa- 
tion about the act that caused the format- 
ting to occur. (A more detailed discussion 
of the interactive versus batch formatting 
question is presented in Section 5.) 
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The user interface is designed for various 
levels of expertise. The user can call a menu 
to the screen at any time and select a com- 
mand with cursor keys or a pointing device. 
Alternatively, the user can type a command 
to perform the same action — or use spe- 
cialized function keys provided for the most 
widely used commands. 

The system provides a cancel command 
to abort the current operation, an again 
command to execute the current command 
again, and an indefinitely deep undo facil- 
ity. The same tree structure that keeps 
track of the undo history is used in a help 
command that creates windows to show the 
user the session’s history and what options 
are currently available. When the help com- 
mand is invoked, the user is presented with 
descriptions of a few past operations plus 
what is currently being done. 

1.5 General-Purpose Structure Editors 

Structure editing, pioneered by Englebart 
with NLS, has been “rediscovered” as an 
alternative to standard character-oriented 
methods of editing. Since most target ap- 
plications have some innate structure (e.g., 
manuscripts are composed of chapters, sec- 
tions, paragraphs), the philosophy of struc- 
ture editors is to exploit this “natural” or- 
dering to simplify editing. The most com- 
mon representation is a hierarchy of ele- 
ments. Standard operations on this tree 
structure, as taken from XS-1 [Burk80], 
are shown in Figure 13. 

1.5.1 NLS/ AUGMENT 

NLS was a product of research at Stanford 
Research Institute (now renamed SRI, In- 
ternational) between the early 1960s and 
late 1970s. Renamed AUGMENT and mar- 
keted by Tymshare, Inc., NLS is one of the 
seminal efforts in the field of text editing 
and office automation; indeed, many of its 
features are being reexamined and reimple- 
mented today — almost 20 years since the 
inception of the NLS project. For example, 
NLS introduced the notion of conceptual 
models for the editing and authoring pro- 
cesses, (tree-) structured editing, element 
modifiers for the editing and viewing oper- 
ations, device-independent interaction syn- 
tax, the mouse as a cursor manipulation 
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World Wide Word Processing Inc. 
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Cupertino, CA 95014 
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Dear John: 

We are pleased to hear of your interest in our ETUDE 
text formatting system, which is now available for 
demonstration. Enclosed you will find a copy or our 
working paper entitled An Interactive Editor ondFctmailrr 
which will give you an overview of some of the goals ol 
our research. This research is funded by a contract with 
Exxon Enterprises Inc. 

Our efforts have been guided by a number of general 
principles: 

1. ETUDE should be easy to use. The system 
should respond in a reasonable manner, 
regardless of the user’s input. In particular, 
the user should not be reluctant to try • 
command, for fear of losing the current 
document. 

2. A user of ETUDE should not be concerned 
with the details of a document’s formatting 


Figure 1 2. ETUDE screen. (Courtesy M.I.T. Laboratory for Computing Science.) 
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INSERT 

Insert a new site (with empty data 
collection) Into a specified gap 

DELETE 

Delete a subtree (nodes and data) 
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Permute the nodes on a tree level 1 


Figure 13. Tree editor functions of a 
structure editor. (Adapted from BuukSO.) 
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device, sophisticated browsing and viewing 
mechanisms, intermixed text and graphics, 
and even multiperson, distributed editing. 
At a spectacular, landmark demonstration 
of the system at the 1968 Fall Joint Com- 
puter Conference in San Francisco, text, 
graphics, and live video of Douglas Engel- 
bart in San Francisco and his colleagues 20 
miles away in Menlo Park were superim- 
posed on multiple viewports on the (video 
projected) screen, as they were working 
together and explaining what they were 
doing. “Chalk-passing” protocols were 
demonstrated for synchronizing multiple 
users. This demonstration was a forerunner 
of graphics- and sound-based teleconfer- 
encing. 

NLS/AUGMENT clearly embodies 
much more than just a text editor. Its aim 
is to provide a new way of thinking and 
working by utilizing the power of the com- 
puter in all aspects of one's work: 

We are concentrating fully upon reaching the point 
where we can do all of our work on line — placing in 
computer store all of our specifications, plans, de- 
signs, programs, documentation, reports, memos, 
bibliography and reference notes, etc., and doing all 
of our scratch work, planning, designing, debugging, 
etc, and a good deal of our intercommunication, via 
consoles. [EngeG 8, p. 396. Reprinted by permission 
AFIPS Press] 

Regardless of the subject matter, all NLS 
information is stored in a hierarchical out- 
line structure of the form 

1 . . . 

la . . . 

lb. .. 

1 bl ... 

Ibla . . . 

1 b2 . . . 

1 b3 . . . 

1 b4 . . . 

1 b5 . . . 

2... 

2a. . . 

3 . . . 

4 . . . 

4a . . . 

4a1 . . . 

4a2 . . . 

Statements can be nested an arbitrary 
number of levels. Each statement has as- 


sociated with it a statement number of the 
form shown above; these are the main 
means of referencing the statements from 
other parts of the text. One statement may 
be a substatement of another statement 
(lal is a substatement of la), one may be 
the source of another (la is the source of 
lal ), one may be the predecessor of another 
(4al is the predecessor of 4a2), or one may 
be the successor of another (4a2 is the 
successor of dal). NLS provides modifiers 
to reference not only text elements but 
structure elements as well. A statement is 
a text node of up to 2000 characters. A 
branch is a statement and all its substate- 
ments. A plex is a branch plus all the other 
branches with the same source. The plex of 
4al is 4al and 4a2; the plex of 4a2 is the 
same. A group is a subset of a plex; it 
consists of all the branches of a plex that 
lie between and include two branches. The 
group of lb2 and lb4 includes lb2, lb3, and 
lb4. 

The hierarchy is useful for programs as 
well as for documents since it can be used 
to model the block structure of the pro- 
gram. Viewspecs allow levels of detail in 
the outline structure to be made invisible; 
the viewspecs effect information hiding, 
the selective display or nondisplay of exist- 
ing material based on attributes provided 
by the user. 

NLS/AUGMENT allows the user to cre- 
ate a hypertext by superimposing on the 
structure a network of links that point to 
various discrete statements in this docu- 
ment. In general, these links are specified 
by the identifier 

(host, owner, file, statement) 

which allows the linking of documents over 
multiple computers. 

Commands in NLS/AUGMENT can be 
executed by using a mouse to select from a 
menu on the screen, by using the keyboard, 
or by using both the keyset (described in 
Part I, Section 2) with one hand to enter 
the command, and the mouse with the 
other to make a selection. 

The editing commands are quite exten- 
sive, providing the first attempt at an or- 
thogonal command syntax with element 
modifiers. For instance, the insert com- 
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mand can be modified, with nouns such as 
word, sentence, and branch. As in most 
structure editors, the commands are di- 
vided into those that operate on the struc- 
ture (such as move) and those that operate 
on the text. NLS/AUGMENT provides a 
very large repertoire of both. Most standard 
tree manipulations, such as locating or de- 
leting the next node or the previous one, 
locating the first, subnode, and rearranging 
neighboring nodes, are allowed. The move 
and copy structure commands provide dy- 
namic renumbering of sections and updat- 
ing of links throughout the document if 
necessary. 

The system provides the ability to embed 
control codes in special delimiters within 
the text both for formatting options such as 
font changes and for traveling information 
(links, annotations). These codes can be 
edited like regular text until they are in- 
voked by special commands (a link is not 
operable until the jump command is in- 
voked). Viewspec parameters allow one to 
turn off viewing of these special codes as 
desired. 

A journaling facility provides extensive 
archiving power for past on-line conversa- 
tions and teleconferences. Tymshare’s com- 
mercial version of AUGMENT makes use 
of TYMNET, a transcontinental satellite 
network, to satisfy one of the original goals 
of the project: the sharing of knowledge 
across great distances. In fact, it is not 
uncommon for someone in New York to 
compose a document by making several 
links to an existing document belonging to 
a colleague in California. 

At its time of introduction, NLS was 
unusual not only in terms of its functional- 
ity but also because of the software engi- 
neering environment in which it was pro- 
duced. This environment included compiler 
compilers, systems implementation lan- 
guages, and command language inter- 
preters. 

f.5.2 Burkhart/ Nievergelt Structure Editor 
Burkhart and Nievergelt at the Institute 
for Information in Zurich have designed a 
family of structure-oriented editors called 
XS-1 [Burk80], The designers contend 
that the basic sets of editing operations, 
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regardless of the target being manipulated, 
are similar, and that “a universal structure 
defined on all data within a system ex- 
ploits that similarity to its greatest advan- 
tage. As in NLS, the structure of data of all 
types in XS-1 is represented as a tree, with 
the nodes (“sites”) representing subsets of 
data. Like many structure editors of its 
kind, the core of the XS-1 system is a 
flexible tree editor that allows the user to 
manipulate the elements at the site (node) 
level. Fundamental to the XS-1 philosophy 
is the belief that the user works only on a 
restricted set of data and with a restricted 
set of commands at any one time. There- 
fore, the system supports progressive dis- 
closure, explicitly showing the user the 
valid command repertoire and operation 
targets at any given moment. The user al- 
ways has the familiar tree operations avail- 
able at all times. 

XS-1 provides the user with standard 
structure editor methods of travel through 
the explore command. Here, the user can 
use relative motion to traverse up, down, 
left, or right in the tree. As well, absolute 
motion allows the user to move explicitly to 
something by specification of an identifier 
such as a name. 

The tree editor follows several basic prin- 
ciples. After the completion of any opera- 
tion, the integrity of the tree structure is 
guaranteed. (This may be accomplished by 
attaching target-specific syntax rules to op- 
erations, making a syntax-directed editor.) 
XS-1 provides the ability to specify differ- 
ent views of the same targets, such as a Iree 
structure of a program or an indented view 
of the same program. 

An important aspect of XS-1 is the com- 
bination of the same target-independent 
tree editor with target-dependent back ends 
to create multiple editors. One is a docu- 
ment editing/formatting system. Here, the 
author sees on the screen a rectangular 
window into the text and a text cursor. All 
high-level operations (move, copy, etc.) are 
handled by the target-independent tree ed- 
itor; only a small set of text editing primi- 
tives at the character, word, or sentence 
levels is provided. The command set is con- 
sistent between targets; operations pro- 
vided by the universal editor are also pro- 
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vitled for specific target-dependent modes, 
enabling the user to deal with a relatively 
small set of operations that do “obvious" 
things. For example, a move command in a 
text editor would move the selected text 
from source to destination, while a move 
command in a graphics editor would move 
the selected graphics object from source to 
destination. Text formatting is done by ap- 
pending a formatting descriptor to each 
site; these can be edited by the tree editor 
as well, j j 

>S ftC ‘f!'i I' I I 

1.5.3 Fraser's s 

Fraser’s s [Fuas 80] is an attempt to provide 
standard editing primitives that can be used 
to build a variety of editors, s allows the 
programmer quickly to create different 
front ends for a text editor so that various 
targets can be modified using existing edit- 
ing routines. 

The philosophy behind s is that many 
computer utilities— interactive debuggers, 
file system utilities, even tick-tack-toe 
games — are simply editors in that they ac- 
cept a particular input syntax and modify 
the existing representation and/or state of 
their particular data. Rather than produc- 
ing languages and scanners for each appli- 
cation, s attempts to use a generalized 
structure and a generalized text editor nu- 
cleus for editing all applications. 

One application allows the user to edit 
UNIX i nodes, complex (18-field) data 
structures containing pointers and infor- 
mation about a file block from the UNIX 
'file system. When the system crashes of a 
disk block becomes unusable, the systems 
programmer occasionally has to go into the 
file system and manually change pointer 
values from a dump-type format, s pro- 
vides a screen-based view of the file descrip- 
tor, allowing the user to' edit each of the 
fields, which are represented one jrer line. 
An overstrike, for example, is translated 
into? a call to' the nucleus routine fetch to 
retrieve the appropriate field and a call to 
the nucleus routine change to update the 
field. The deletion of a field would be per- 
formed with a call to the nucleus routine 
. delete. * whmiuho u 

Another interesting use of s is as a UNIX 
file directory editor. The UNIX Is -I com- 


mand provides .1 lisiing of file attributes: , 

dr«r-xr-I 2 Lion 2.4 IUj 0 15:27 bBACKVP 

-I¥-r — r — 1 Urn 365U5 UkJ 2 16:42 S4Ctlonl . ttx 

-inmin 1 aim 16714 Apr 25 17:11 • action. t« 

-rw-r — r— 1 nlm 46414 Vaj 2 16:44 mctlon3. t«i 

-r«-r— r— 1 Ota 55282 ll»J 6 00:23 • •ctloo4>.tn 

-rw-r— r— 1 nta 20113 UkJ 6 00:40 ••Ctloo4i2.t«l 
-rw-r— r— 1 nlm 0200 Xaj 0 14:50 nct.loii4b.tii 

-rw-r— r— 1 dJcb 22040 Uij 0 14:20 wictlon4c.ttx 

-rw-r— r— 1 Dim 26058 UkJ 6 02:24 81ctlon4d.twx 

-rw-rw 1 nta 3362 u»y o 15:10 wwctlon4t.twi 

-rw-rw 1 oka 16541 Wwj 7 11:13 wwctlons.tii 

The first field contains a d if that entry is 
a directory; this field is not editable. The 
next nine fields contain r, w, and x for read, 
write, and execule privileges for the owner, 
the group, and for all others, respectively, 
with a - indicating no access. The next 
field, the link count, is not editable. The 
next field contains the owner of the file. 
The rest of the fields are not editable/ex- 
cept for the last entry, the actual file name. 

Rather than forcing the user to use the 
UNIX shell commands for performing re- 
naming (mv oldname newname), deleting 
(rm filename), changing ownership (chown 
filename), and changing access rights 
(chmod a+rwx filename to allow all to read, 
write, and execute the file), the s directory 
editor allows the user to edit the listing 
directly, barring protected fields. Deleting 
the characters, r, w, or x removes read, 
write, and execute access for the corre- 
sponding parties; overstriking a - with r, 
w, or x adds access. Typing over the owner 
name changes the owner, typing over the 
file name changes the file name. Deleting 
an entire line deletes that file. 

A different front end allows the user to 
edit the state of a simple pedagogical com- 
puter. Rather than having the student sub- 
mit punched cards in batch mode and easier 
and cheaper than having a physical labo- 
ratory machine, an s front end was written 
representing the machine architecture as 
editable lines and allowing the students to 
modify the appropriate fields. While the 
goals of the i node and machine applications 
are different, the primitives to edit them, at 
least from a system view, are the same. 

While the s editor was a limited experi- 
ment, its ramifications are wide ranging. 
Many applications, especially ones that are 
computer based, have some aspect that re- 
quires editing. We feel that Fraser’s basic 
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premise — when changing a file name in a 
file system, when adding a user lo a mailing 
list, or when editing a UNIX i nude as 
above, there is no reason why the user 
should have to resort to special mainte- 
nance programs — will be an important goal 
in the future of editing. As Fraser's s has 
shown, a general-purpose editor can he used 
to give the user a far more common inter- 
face across diverse applications than typi- 
cally exists today. Moreover, with an appro- 
priate interface, one can perform editing on 
a graphical representation of the target 
rather than on an unfamiliar, textual rep- 
resentation. 

1.5.4 Walker's Document Editor 
Walker’s Document Editor is an attempt to 
design an editor for the preparation of com- 
plex documents such as technical manuals. 
An initial goal of the system was to 
“develop a structured description for doc- 
uments . . . distinct from any particular 
commands in the document source” 
[WALK81b, p. 44]. The Document Editor 
uses EMACS as a base text editor and 
Scribe as a document-description database 
and compiler. 

The Document Editor operates on a 
“document” as a collection of files in Scribe 
manuscript file form; it infers the structure 
of the document from the tags in the file 
being edited. The specialized functions for 
technical writing provided by the Docu- 
ment Editor are actually extensions to 
EMACS in the form of a user library. 

The Document Editor provides four ma- 
jor categories of document structure editing 
commands: locators, selectors, mutators, 
and constructors. Locator commands allow 
the user to specify places in the document; 
these include commands to go up and down 
a structural level (e.g., from section to sub- 
section), to go to the next or previous item 
at the same structural level, and to go to 
the next structural element of any type. 
Selector commands allow the user to deter- 
mine the current makeup of the document 
by checking the status of the parts and the 
structure of the document at various (user- 
specified) levels. Mutators revise the struc- 
tural makeup of the document, providing 
functions such as change structural level 
(e.g., make a chapter a section). Construc- 


tors allow the user to create and copy struc- 
tural elements. 

The Document Editor uses Scribe’s 
cross-referencing commands for maintain- 
ing cross-references for section numbers, 
table numbers, and other document infor- 
mation. This facility provides a follow 
CREF (cross-reference) pointer function to 
allow the user to view the target of the 
cross-reference. More interestingly, it con- 
tains the find all fingers function, which 
allows the user to see which cross-reference 
pointers in the document point to a partic- 
ular spot in a document. This forms a ru- 
dimentary hypertext capability [Nki.s67, 
VAND71a], but requires the high computa- 
tional overhead of being extrapolated from 
Scribe, rather than being an editor primi- 
tive. 

The Document Editor uses the cross-ref- 
erence capabilities to provide functions that 
manage the task of creating an index for a 
document. For traveling, the user can fol- 
low an index pointer and examine all the 
fingers pointing to a location, as well as 
make an index entry, show index symbols, 
and find all the index symbols containing a 
particular word. 

The Document Editor runs Scribe as an 
underlying formatting process. The editor 
itself, EMACS, does not present the for- 
matted text for the user to edit. As dis- g 
cussed in more detail in Section 2, Walker 
contends that for large documents, one has 
little interest in anything but the content 
and the formatting abstractions (as op- 
posed to the actual formatting) during most 
of the life of the document. However, the 
Document Editor does provide the func- 
tions for compiling those parts of the doc- 
ument that have actually changed, while 
conforming to the formatting constraints of 
the entire document (proper page numbers, 
indentation levels, margins, typefaces). 

This alleviates the cost of recompiling an 
entire document because of minor editing 
changes. 

1 .6 Syntax-Directed Editors 

Syntax-directed editors attempt to increase 
the productivity of the programmer by re- 
moving the time-consuming process of 
eliminating syntax errors. Syntax editors 
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are structure editors that ensure that the 
structure always is constrained to preserve 
syntactical integrity. Often syntax-directed 
editors do not merely recognize the syntax 
and translate the user’s actions into linear- 
text, but instead parse the input into an 
intermediate form that can be used to gen- 
erate code. Here the editor is both a tool 
for the programmer and a tool for the com- 
piler/interpreter. We give some prototypi- 
cal examples below. 

1.6.1 Hansen's EMILY 

Hansen’s EMILY [Hans 71] is one of the 
earliest syntux-directed editors. Rather 


The user selects the second with a light pen 
and gets the expansion 

IF ItEXP R j| THEN 
(STMT ) 

The current nonterminal is now [(EXPR)j , 
and the menu displays the possible expan- 
sions for this. Subsequent derivations to 
arrive at the appropriate IF clause are 

IF gVAR>j THEN 
(STMT) 

IF FIRSTTIME THEN 



IF FIRSTTIME THEN DO; 



than typing in arbitrary text, the user cre- 
ates and modifies text by graphically se- 
lecting units of text (templates) that are 
constructs in a programming language. 
Text is created with a sequence of selec- 
tions. The screen is divided into three areas; 
text, menu, and message. The text area in 
the upper two-thirds of the screen displays 
the text under construction as a string that 
contains the nonterminals (nonatomic en- 
tities) of the program, highlighted by un- 
derlining. The current nonterminal is en- 
closed in a rectangle. The menu in the lower 
third of the screen displays a set of possible 
replacements for the current nonterminal. 
The user selects a replacement rule and the 
system makes the substitution, locates a 
new current nonterminal, and displays a 
new set of choices. The message area is 
used for entering identifiers and also dis- 
plays status and error messages. Assuming 
a partial PL/I-type grammar like 

(STMT) ::= (VAR) = (EXPR>;| 

IF (EXPR) THEN (STMT>| 

DO; (STMT*) END; 

(STMT*) (STMT) | (STMT) (STMT*) 
(EXPR) (EXPR) + (EXPR) | (VAR) 

(VAR) id 

where symbols surrounded by “(” and “)” 
are nonterminals, an IF statement might be 
created in the following manner. 

The current (boxed) nonterminal is 
1<STMT)| , and the menu displays the three 
choices 

(VAR) = (EXPR); 

IF (EXPR) THEN (STMT) 

DO; (STMT*) END; 
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END; 

IF FIRSTTIME THEN DO; 

FIRSTTIME = FALSE; 

SYMBOLS = NULL; 

ENDTIME = DAYMINUTES + 10; 

END; 

Since a syntax imposes a hierarchical 
structure on text, EMILY can be used for 
any hierarchical text structure. Each selec- 
tion from the menu generates a node with 
space for one pointer for each nonterminal 
in the replacement string. When a nonter- 
minal is replaced, the corresponding space 
is filled in with a pointer to the node gen- 
erated for the replacement. Each nonter- 
minal thus generates a subtree of nodes 
that is presented on the display, through a 
tree-walking display routine, as a string of 
text. 

As in NLS, the user can change the view 
of the text, so that the string generated by 
any nonterminal is represented by a single 
identifier called a holophrast. For example, 
the IF statement above could be displayed 
with all text generated from the (STMT*) 
represented by a holophrast. In larger pro- 
grams, this feature means that the user can 
view the structure of the text without view- 
ing the details. Alternatively, the user can 
descend into the structure and view the 
details in full. 

Text is also modified in terms of its struc- 
ture. The text represented by any holo- 
phrast can be deleted, moved, or copied. 
When text is deleted, it is not destroyed 
immediately, but is automatically moved to 
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a special system fragment called »DUMP*. 
If a mistake is discovered before the next 
text modification is made, the deleted text 
can be retrieved from this dump. 

EMILY is a pure syntax-directed editor. 
Statements are derived by the menu-pick- 
ing scenario down to the lowest level, for 
example, the identifier. This makes the ed- 
iting awkward, since the user must often 
traverse long derivations to type in a simple 
identifier or assignment statement. 

1.6.2 Cornell Program Synthesizer 

Much work in individual areas was done 
after EMILY, most notably the MENTOR 
[Donz75, Donz80] tree-manipulation and 
programming environment, the CAPS di- 
agnostic programming system [Wilc76], 
and the INTERLISP Programmer’s Assis- 
tant [TeiW77]. The Cornell Program Syn- 
thesizer [TEiT81a, TEiT81b], running on 
both the Terak (LSI-11 based) personal 
computer and the VAX family of com- 
puters, combines many of the ideas from 
these and other projects into a syntax-di- 
rected editor and programming environ- 
ment for PL/CS, and more recently, 
PASCAL. 

In the Synthesizer, designed for simple 
terminals which use cursor keys as the only 
locator device, the user types textual com- 
mands that represent the set of possible 
expansions of the current nonterminal. The 
set of possible commands can be displayed 
in an optional window so that the user need 
not memorize the command sequences. The 
synthesizer differs markedly from EMILY 
in that it is not a pure derivational syntax- 
directed editor. Rather, the synthesizer is a 
hybrid between the traditional structure 
editor and the character-string text editor. 
Thus common elements such as identifiers, 
expressions, and assignment statements do 
not have to be considered as elements of a 
tree structure, nor do they have to be edited 
and stored as such. 

The user is presented with three types of 
high-level entities. Templates are program 
constructs that need to be filled in. Place 
holders are tags in the template describing 
the parts that need to be completed, and 
these are the only parts of templates that 
can be altered. Phrases are pieces of text, 
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not structure, that are typed in lo replace 
place holders. 

To start a PL/CS program editing ses- 
sion, the user types ‘main followed by a 
carriage return to obtain the template for 
a PL/CS main program. 4 This template is 
of the form 

/• comment •/ 

file-name: PROCEDURE OPTIONS (MAIN); 
(declaration) 

(statement) 

END file-name; 

The user can position the cursor at the 
place holder comment and type a phrase 
containing the text of a comment. Now the 
user positions the cursor at the place holder 
for the nonterminal declaration. Since this 
is a nonterminal (indicated by the braces), 
the user must select an applicable template 
for further derivation. At this point, the 
user can type «fx for a fixed variable, Ml for 
a float variable, *bt for a bit variable, *ch 
for a character variable, or »c for a com- 
ment. For our example we choose *fx. This 
expands to the template 

DECLARE (list-of-variables) FIXED [attributes]; 

The cursor is moved to the list-of-variables 
place holder, and a phrase containing the 
name of the variable is typed in. This name, 
typed in as text, not as structure, is parsed 
for syntactic correctness upon pressing car- 
riage return, and is stored and manipulated 
as text. If an illegal variable name is typed, 
this phrase is highlighted in reverse video 
and flagged internally. If the attributes are 
not inserted, the square brackets indicate 
that default values will be used. The dec- 
laration nonterminal is now completely de- 
fined, and the user moves on to expand the 
statement nonterminal, for which there are 
13 possible templates. Typing Me generates 
the template 

IF (condition) 

THEN Statement 
ELSE statement 

(The box here indicates the current cursor 
position.) Typing *p at this position gener- 


‘ *, long, clip, delete, left, right, up, down, and diagonal 
are function keys on the synthesizer keyboard. 
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ates the PUT template, giving 
IF (condition) 

THEN PUT SKIP LIST (Qist-of-expressions); 

ELSE statement 

The user could then type a phrase like 
“ 'min = '.beta ” to fill in the place holder. 

The user uses the left, right, up, and down 
cursor keys to traverse the structure. In 
fact, the key names do not represent the 
true functions attached to those keys. Right 
and down both move the cursor forward 
through the program; left and up move it 
backward through the program. Rather 
than moving character by character, these 
keys move the cursor one program element 
(template beginning, place holder, or 
phrase) at a time. Left and right, addition- 
ally, stop at each individual character in a 
phrase. In an expanded template like the 
one above, the cursor would stop at the 
underscored places when using up and 
down: 

IF ( alpha < beta) 

' THFFfPUT SKIP LIST (‘min = '.beta); 

ELSE statement 

and at these underscored places when using 
left and right: 

IF ( alpha < beta ) 

THEN PUT SKIP LIST ( 'min = '.beta ); 

ELSE statement 

The two-key sequence long down (up) 
moves the cursor to the next (previous) 
structural element of the same level. Other 
keys move the cursor to the nearest enclos- 
ing structure template and to the beginning 
of the program. 

Insertion and deletion are based on the 
pick, put, and delete buffer concepts. The 
user positions the cursor at an appropriate 
template or phrase, and then issues the 
delete command to delete that template 
(including, of course, all subtemplates) or 
phrase and store it in the delete buffer. 
Similarly, clip will store a copy of the se- 
lected entity in the clip buffer, but not 
delete the original. The insert command 
allows the reinsertion of the deleted or 
clipped text at the current cursor position. 
In the above example, if the cursor were 
positioned at the P in “PUT,” the sequence 
delete, down, insert would result in the 


program segment 

IF (alpha < beta) 

THEN statement 

ELSE PUT SKIP LIST ('min = ', beta); 

Correcting mistakes can only be done by 
preserving structural integrity. Assume the 
following incorrect code segment: 

/» compute factorials from 1 to 10 nonrecur- 
sively */ 
a = 0; 

DO WHILE (a < 10); 
a = a + 1; 
fact = 1 ; 

PUT SKIP LIST (a,' Factorial ='); 
temp = a; 

END; 

DO UNTIL (temp = 1); 
fact = fact • temp; 
temp = temp - 1 ; 

END; 

PUT SKIP LIST (fact); 

The traditional programmer, realizing that 
the END of the DO-WHILE loop should 
properly come at the end of all of this code 
(nesting the DO-UNTIL and the PUT SKIP 
LIST), would move the END statement to 
the end of the code with a single move 
command or a delete/puf sequence to 
achieve 

/• compute factorials from 1 to 10 nonrecur- 
sively •/ 
a = 0; 

DO WHILE (a < 10); 
a = a + 1 ; 
fact = 1 ; 

PUT SKIP LIST (a,' Factorial ='); 
temp = a; 

DO UNTIL (temp = 1); 
fact = fact • temp; 
temp = temp - 1; 

END; 

PUT SKIP LIST (fact); 

END; 

In a syntax-directed editor, since the END 
is part of the DO-WHILE template, it cannot 
be separately moved. Instead of moving the 
END forwards, the equivalent backward 
move of the two following statements must 
be done. To perform the desired alteration, 
the user would have to position the cursor 
at the start of the DO-UNTIL template, 
press long delete, move the cursor to the 
last element in the list of structures to be 
moved (the PUT SKIP LIST (fact) state- 
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ment), signal completion of the selection by 
typing •, move the cursor to the structural 
element after which the new part should be 
inserted (the temp = a; phrase), press car- 
riage return to open a statement place 
holder, and issue *ins DELETED to position 
the desired text in the desired spot. While 
this is certainly more complicated than the 
traditional method, the interface is partially 
to blame. A pointing device that would 
easily allow selection of elements and ex- 
tension by structural or contiguous units 
would eliminate many of the keystrokes 
above. Even without the pointing device, 
one could imagine extending the starting or 
ending portions of a template to encompass 
contiguous statements. 

Even if many syntax-directed editing 
techniques are nominally longer than tra- 
ditional techniques, the excess time must 
be weighed against the time saved by en- 
suring that a program is syntactically cor- 
rect every step of the way. One major time- 
wasting operation that is avoided is the 
back mapping of frequently inscrutable 
syntax-error messages to the source lines, 
all too often a heuristic and frustrating 
process. Indeed, an important contribution 
of the Synthesizer project was the concept 
of the syntax-directed editor as an integral 
part of a programming environment. The 
Synthesizer is not typically used to create 
text files that will later be passed to a 
standard compiler, but rather as an editor 
that will create a representation of a pro- 
gram suitable for on-line interpretation. 
The Synthesizer allows the user to run a 
program and watch the cursor step through 
the lines of code as they are being executed, 
much like the “bouncing ball” familiar to 
cartoon watchers. Information hiding (such 
as seeing only the comments or top-level 
templates) still allows single-step viewing 
of the program in which the cursor jumps 
from one visible high-level unit to the next, 
the user does not have to watch the low- 
level details, for example, the inner work- 
ings of a loop. Uninitialized variables are 
flagged, type checking is enforced interac- 
tively, and duplicate declarations are pro- 
hibited, all at edit time, rather than at 
compile time. Invalid phrases are high- 
lighted as soon as the user types them in. A 
syntax-directed approach avoids the time- 
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consuming back-mapping error messages 
from a batch compiler to the proper lines 
in the source file by generating the error 
messages interactively, with the offending 
program components highlighted. Pro- 
grams are incrementally compiled, allowing 
the user to reedit and experiment with 
small parts of a program without waiting 
for an extensive recompilation. In fact, the 
approach taken with the Synthesizer allows 
the suspension of program state, the correc- 
tion and incremental compilation of a por- 
tion of the program, and the resumption of 
the program. 

Templates can be input only in a struc- 
turally sound manner, while phrases, typed 
textually, are allowed to be erroneous. 
When editing, the user does not need to 
expand all nonterminals or remove all er- 
rors in phrases. An incomplete or erroneous 
program can be run at any time. However, 
these irregularities are highlighted from the 
moment they are input until the moment 
they are corrected; the synthesizer relaxes 
some of its constraints, but warns the user 
accordingly. In both cases, the program will 
run normally until the error or unfinished 
program construct is encountered. When 
this is encountered, the user is free to cor- 
rect or insert the code and continue the 
execution. 

The program is stored as a combination 
of a parse tree for the templates, and as 
actual text for the phrases. The pretty- 
printed code that the user sees is actually 
an interactively generated view of the in- 
ternal data structure. 

Currently, a Synthesizer Generator is 
being developed which will allow a com- 
plete syntax-directed editor to be generated 
from a formal description of the syntax. We 
point the reader to the GANDALF project 
at Carnegie-Mellon University [Habe79, 
Notk79, Feil80, Medi81] for a description 
of a similar syntax-directed editor and edi- 
tor-generator project. 

1.6.3 Fraser's sds 

Fraser’s sds is a general structure editor 
driven by a grammar that describes a hier- 
archical data structure, Our interest in it 
results from the stress that has been put 
upon imposing a syntax on targets that are 
not necessarily programs, and upon the 
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generation of the editor from a procedural 
description. 

The user-viewable part of sds is a screen 
editor which displays a current record of 
some tree structure. The cursor keys down, 
up, left, right and home allow the user to 
move down to a node field, back up, left or 
right to adjacent fields, or to the root of the 
structure. Other commands consist of typ- 
ing a period followed by the name of a 
nonterminal, the technique used in the Cor- 
nell Program Synthesizer. This causes the 
editor to allow the user to enter the first 
field of this new nonterminal. The user can 
either enter another nonterminal designa- 
tion or, if applicable, simply type a string 
that will become a terminal or leaf node. As 
well, sds provides target-independent com- 
mands such as .w (.r), which write (read) a 
subtree to (from) a file, .hide(.show), to 
suppress (exhibit) detail of a subtree, .pick, 
which saves a pointer to the current node, 
and .put, which substitutes the current 
node with the previously picked node. 

The target-specific editor is v. i itten using 
a formal syntax description similar to that 
used for the YACC compiler-compiler of 
Johnson [John75], The entire grammar for 
an sds binary tree editor is captured in one 
line: 5 

tree = value tree tree : dotree(value, tree, tree2) 

The phrase before the colon is the gr am- 
matical description of tree, the only pro- 
duction in the grammar of binary trees. The 
portion after the colon is SNOBOL4 code 
to perform an action (tree2 is the second 
argument named tree, treen would be the 
SNOBOL argument for the rath tree token 
in a production list). In this example, the 
dotree subroutine contains SNOBOL code 
to display the value and the two subtrees 
in graphical form. Note that to change the 
representation of a binary tree node to one 
in which the value lay between the two tree 
pointers, one would simply have to change 
the production to transpose the words 
“value” and “tree”: 

tree = tree value tree : dotreefvalue, tree, tree2) 

Similarly, the dotree routine could be 
changed to store the binary tree in a disk- 

5 Eiamples are adapted from Fras81. 


oriented form or to print it in an indented 
representation; the actions are independent 
of the creation routines of sds. 

A document editor has also been written 
in sds. Of course, this implies the construc- 
tion of a hierarchical grammar for a docu- 
ment, coupled with action rules for each 
production. A sample grammar for a small 
document system looks like 

paper = title sect:center(title) nl nl 
generate(sect) 

sect = header pp sect : header nl nl put(pp) 
generate(sect) 

pp = text pp:break(text) nl generate(pp) 

To the right of the colons lie production- 
specific SNOBOL code. We are concerned 
here only with the productions to the left 
of the colon. 

To use this editor, the user would enter 
textual commands to create various levels 
of the subtree as follows. The prompt line 
gives the user an idea of location in the 
structure. The last item on the line is the 
current field (item on the right side of the 
production), while the preceding items are 
the types (items on the left side of the 
production) which brought the user to that 
field, that is, the successive nodes of the 
tree branch. The root name paper is im- 
plied at the beginning of each line. 

First, the user types .paper, telling sds to 
begin a node of type paper, the root of the 
structure: 

prompt: 
user: .paper 

The next prompt asks the user to type in a 
title and go to the next part of the produc- 
tion: 

prompt: title 

user: Interactive Editing Systems 

sds is now ready to perform the sect pro- 
duction, but requires the user to issue the 
explicit command to create the section: 

prompt: sect 
user: .sect 

Having created the .sect record, the system 
prompts the user to fill in the header field: 

prompt: sect header 
user: Introduction 
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The user is now prompted to create a pp 
record, and again musL issue an explicit 
command: 

prompt: sect pp 
user: .pp 

The user is prompted to enter text. In this 
mode, he is provided with a target-depen- 
dent text editor based on the Irons model: 

prompt: sect pp text 

user: The interactive editor has become an 
essential. . . 

Upon terminating the paragraph, the user 
is prompted to create another, as the pp 
production is recursive: 

prompt: sect pp pp 
user: .pp 

The user then types in the appropriate text: 
prompt: sect pp text 

user: Though the editor has always been 
deemed. . . 

The command up goes up one level in the 
structure. This causes a production (pp = 
text pp) to be completed and an action to 
be performed, in this case, formatting of a 
paragraph: 

prompt: sect pp pp pp 
user: up 

We go up one more level of the tree, for- 
matting the first paragraph. 

prompt: sect pp pp 
user: up 

While the user is entering text, sds is per- 
forming syntax checking, flagging and pro- 
hibiting invalid structure at any point in 
the document. 

Initial reaction to document creation by 
structure centers on the apparent 
“wordiness” necessary to get the job done, 
but Fraser contends that the explicit struc- 
ture is almost identical to what one does 
implicitly with a compiler-based document 
language. In fact, the .w command would 
store the above paper as 

.paper 

Interactive Editing Systems 
.sect 

Introduction 

•PP 


The interactive editor has become an essen- 
tial. . . 

■ PP 

Though the editor has always been deemed. . . 

A third application for sds is as a picture 
editor for simple line drawings. The struc- 
ture editor, using the small six-line gram- 
mar described in Fras81, would create the 
multicolor letter “T” with the structure 

.branch 

.color 

blue 

.line 

0,20 20,20 
.color 
.red 
.line 

10,0 10,20 

Other grammars used by sds include one 
for a subset of C [Kern78c]. 

1 .7 Word Processors 

1.7.1 WordStar 

WordStar [Micr81] is one of the most pop- 
ular word processing programs available for 
home computer systems. It runs on a vari- 
ety of systems under the CP/M operating 
system, using the CP/M file system to 
maintain its files. 

The conceptual model of text in Word- 
Star is the quarter-plane of the Irons model. 
Control key combinations (special prefix 
characters are used as software shift keys 
to provide a large set of commands), func- 
tion keys and cursor keys are used for com- 
mand specification. WordStar combines the 
quarter-plane model with a “virtual type- 
writer” model. The user is presented with 
a ruler line that simulates tab rack and 
margin ruler on conventional typewriters, 
and with commands to move virtual margin 
keys forward and backward on this ruler 
line. WordStar divides the file into logical 
pages that default to contain 55 lines (the 
number of lines on an 81 x 11 -inch page, 
excluding margins). Most importantly, 
WordStar provides modest interactive edi- 
tor/formatter capabilities for justified, 
monospaced text. As the user types in text, 
the lines are automatically justified. When 
text is changed, rejustification is not auto- 
matic, but is done on a per-paragraph or 
per-document basis by user command. 
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A:TEST.DOC 

PREFIX 


PAGE 1 LINE 3 COL 19 

(to cancel prefix, hit SPACE bar) 


CURSOR: S * left Side screen E =top screen 
R = beginning file C = endfile 

Z=continuous up 
DEL = left 
F= find a string 


X = bottom 
0-9, B, K, V, P = 


D = right enD line 
to marker 


SCROLL: 

DELETE TO END LINE: 
FIND, REPLACE: 


REPEAT NEXT COMMAND:Q = repeat until key hit 


W = continuous down 
Y- right 

A= find and substitute 


-!- 




-I- 




-I. 


-I- 


this is text entered by the user. 

The quick brown fox jumped over the lazy dog. 
abcdefghijklmnop ■ 


Figure 14. WordStar screen. (From Micr 81. Reprinted with permission.) 


The screen is set up to provide extensive 
feedback to the user. The first line is a 
status line: it presents the file name of the 
document, the current page number, and 
the current line and column at which the 
cursor points; as soon as the cursor is 
moved, the latter values are changed. As 
well, the beginning of this line is used to 
echo the typed command. For instance, as 
in Figure 14, if the user types CTRL-Q on 
the keyboard, the textual representation ‘Q 
is shown on the screen. The next few lines 
on the screen (above the ruler fine) repre- 
sent the current options. Here, since CTRL- 
Q was typed, the "Q prefix options are dis- 
played in the help area. The user then 
chooses one of the ~Q suffixes, which rep- 
resent commands. A more sophisticated 
user can avoid this extensive prompting in 
two ways. First, if the entire command, say 
CTRL-QF is typed together quickly, it is 
executed without displaying the ‘Q options. 
More explicitly, the user is given commands 
to' change help levels. These help levels 
range from displays for the novice, contain- 
ing complete options; to those for the ex- 
pert, containing no options at all. The full 
set of WordStar commands is shown in 
Figure 15. WordStar makes sure that the 
user has noticed an error by requiring an 
acknowledgment — by default hitting the 
ESC key — to resume operation. 

As in the Irons model, editing is done on 
the' displayed viewing buffer/editing buffer 
by driving the cursor around and typing: 
WordStar offers both insert mode and 
typeovermode. . a • ,• J . - ..-i ,;j\ ' 


A major flaw of WordStar is the lack of 
an undo facility: once a command is exe- 
cuted, it cannot be reverted. This reduces 
the freedom of experimentation that an 
author should have. The only recourse that 
a user has is “undoing” an entire session 
with an abort command. 

A problem with WordStar, and with most 
microcomputer editors, is lack of both main 
memory and disk space. WordStar, for in- 
stance, has its own paging routines to bring 
parts of documents in and out of. memory. 
If the disks are of reasonable capacity, this 
offers no problem. However, for small sys- 
tems with floppy disks and consequently 
small disk capacity, the amount of the disk 
needed for paging leaves little room for 
document storage. This causes, in some 
systems, the unfortunate situation in which 
a document that is being edited cannot be 
stored back on disk. 

1.7.2 CP r 8000 

CPT is a representative example of a com- 
mercial stand-alone word processing sys- 
tem. The Disktype 8000 has a page-size, 
monospace display, and two floppy disks to 
store files. CPT was the first word-process- 
ing system to offer an 8j X 11-inch white 
screen with black characters, simulating a 
piece of paper in a typewriter [SeyP79], In 
fact, the typewriter metaphor is consis- 
tently applied. A few lines up from the 
bottom of the page is the typing line, meant 
to simulate the paper bail on the platen of 
a typewriter. Input takes place on the typ- 
ing line only. 
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No standard cursor keys exist on the 
CPT. Rather, the space bar moves the cur- 
sor forward on the typing line and the back- 
space key moves it backward. There is no 
need for up and down cursor movement, 
since it is the document that travels up and 
down past the typing line. Therefore keys 
are provided to scroll the document up and 
down. Margins are set by moving right and 
left markers on the typing line. Five other 
keys specify character, word, line, para- 
graph, and page elements for commands 
like delete, skip, move, and insert. 

CPT provides three input modes. Manual 
mode simulates a typewriter; when the user 
reaches the right margin, a bell rings. 
Wraparound mode provides automatic car- 
riage returns when the right margin is ex- 
ceeded. Hyphenation mode performs auto- 
matic hyphenation when a word reaches a 
system-defined “hot zone,” using an algo- 
rithm aided by an exceptions dictionary. 

One interesting feedback mechanism of 
CPT is its error message facility. In the 
center of the status line at the bottom of 
the screen is a 20-character area reserved 
for error messages. Rather than having 
terse error messages in this area, and as an 
alternative to removing some of the possi- 
bly offending text from the display to make 
room for a wordy error message, CPT rolls 
the lengthy error across this area like a 
captioned bulletin at the bottom of a tele- 
vision screen. 

it *• ‘ 51 h • i ' 

1 .7.3 NBI System 3000 

The NBI System 3000 is another popular 
commercial word-processing system. It has 
a stand-alone processor, with file storage on 
floppy disk. Its conceptual model is very 
similar to that of WordStar described ear- 
lier. The interface uses a combination of 
option sheets and function keys; the display 
is a mapping of a screen-sized viewing 
buffer to a full-screen viewport. The user 
alters the documents by driving a cursor 
around the screen with cursor keys, over- 
striking characters or using appropriate 
function keys to effect the changes. Like 
WordStar, the NBI System 3000 supplies 
the user with option sheets to show avail- 
able operations. It does not, however, offer 
the help level commands of WordStar. In 


some cases, the user can operate without 
calling up an option sheet at all, and in 
other cases, as in WordStar, if the user is 
“faster” than the option sheet, it is not 
called up at all. 

NBI presents an interesting alternative 
to the insert mode versus overstrike mode 
“controversy.” When the cursor is posi- 
tioned over a character, typing will over- 
write that character. When the cursor is 
positioned over a space, typing will invoke 
insert mode and all characters to the right 
of the cursor will be pushed to the right as 
necessary. NBI provides an extensive 
search and replace facility, allowing the 
user to perform case-insensitive searches 
and replacements on a case-by-case basis. 

Along with these advantages are several 
inconsistencies. The commands set is not 
consistent. The line delete command will 
delete the line in which the cursor is posi- 
tioned, regardless of where the cursor lies 
in that line, while the word delete command 
will only delete a word if the cursor is 
positioned at the first character of that 
word. Although complete region selection 
and associated copying, moving, deletion, 
and storage are available, NBI provides no 
feedback as the areas are selected. 

1 .8 Integrated Environments 

1.8.1 RIG, Apollo 

The Rochester Intelligent Gateway (RIG) 
user interface [Lant79, Lant80] and the 
similar Apollo Aegis user interface [Apol82] 
are two examples of a relatively new trend 
in editing systems, one in which the editor 
is an integrated part of the interface pre- 
sented to the user, rather than a user-in- 
voked utility program. 

Both the RIG and Apollo systems are 
based on the concept of a display or window 
manager as the primary interface to the 
system. These display managers give tho 
user the ability to create windows on the 
display surface, move these windows 
around, and change their size. On the 
Apollo these windows can overlap; in RIG 
the windows do not overlap but simply 
partition the display screen (see Figure 16). 

As in Star, the windows are meant to 
simulate pieces of paper on a desk. More 
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specifically, the window shows a rectangu- 
lar portion of a two-dimensional pad (see 
Figure 16), an unbounded quarter-plane of 
text. Editing functions much like those in 
Irons model editors are supplied to manip- 
ulate items in the pad. 

So far, the systems sound much like a 
standard multiwindow editor. In fact, one 
of the two types of windows, the editing 
window, fits that model exactly. The other 
type of window, the process window, is an 
editing window with an arbitrary user or 
system process attached to it. The process 
window has both a large output pad window 
on top and a smaller input pad window 
directly underneath. For interactive pro- 


cesses, input is typed into the input pad 
and, much like a typewriter, when a car- 
riage return is pressed, this text scrolls up 
over the “typing bar” into the output pad. 
In addition, output from the interactive 
process is written directly to the output 
pad. The result is a complete transcript, 
simulating output on a hard-copy terminal, 
of the interactive session. Multiple windows 
on the screen may be active at once; the 
user may be reading electronic mail in one 
process window, editing the file referenced 
in the mail in an editing window, and com- 
piling that file in another process window. 
Returning to our editing concerns, we note 
that the output pad allows all editing func- 
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tions (although often the system makes the 
pad’s contents read-only so that they can 
be perused or selected but not altered). The 
user can now travel through the entire con- 
tents of an interactive session, and actually 
select previous input and output from the 
output pad and use it as input elsewhere in 
the system. For instance, the user might 
select a code fragment directly from the 
electronic mail window and insert it in the 
open editing window. 

The major use made of this model is to 
tie to a process window the operating sys- 
tem command interpreter process. Now, 
the user types operating system commands 
into the input pad, and both this input and 
the output of the system programs invoked 
are stored in the output pad. Commands 
can be reexecuted simply by selecting then- 
text in the output pad and inserting it in 
the input pad. Output from a program that 
is lying in an output pad can be selected 
and stored in a file. In fact, an entire output 
pad can be saved as a file if the user wants 
a transcript of an interactive session. 

The ramifications of this concept are 
wide ranging, much like the concepts im- 
parted by the Star interface, but in the 
framework of a general-purpose computing 
system, rather than an office automation 
r system. The editor does not create a pre- 
emptive environment [Swin74] in which 
functions normally available to the user are 
suddenly cut off. Since the editor is now 
above the command interpreter (rather 
than being an applications program in- 
voked by the command interpreter), the 
user can freely issue system commands in- 
terspersed with editing commands. No 
longer does the user have to leave the editor 
to do something as simple as reading elec- 
tronic mail or listing the files in a directory; 
the user simply switches windows momen- 
tarily, executes the appropriate command, 

and returns to the previous window. 

' 

1.8.2 Smalltalk-80 

Smalltalk-80, a research product of Xerox 
PARC’s Software Concepts Group (origi- 
nally the Learning Research Group), pro- 
vides an even more integrated environment 
than described above. In fact, the paradigm 
of overlapping windows was developed as 


part of the Smalltalk-80 project [LRG76], 
Composed of an object-oriented program- j 
ming language and an integrated user 
interface, the Smalltalk-SO 11 [GolA82, 
GolA83] system currently runs on several 
Xerox personal work stations (the Xerox 
1100 Scientific Machine and the Dorado) 
with bit-mapped raster displays and three- 
button mice (see Figure 17). The aim is to 
give the user an interface in which editing 
commands are always applicable and other 
capabilities that the user desires are at hand 
as well. Anything on the screen may be 
edited: document text, commands, program 
code, and so on. The user does not become 
trapped in modes (as in SOS above), but 
always has a full range of choices at any 
point in the editing session. 

The conceptual model provided by the 
Smalltalk-80 user interface [GolA 82] is one 
of views, represented as labeled, rectangu- 
lar, possibly overlapping pieces of paper on 
a desk top. A view is a particular way of 
displaying the information of a task or 
group of tasks for user inspection, altera- 
tion, storage, and retrieval of information. 

The views most used are standard system 
views, on which operations to alter size, 
location, label, and level of detail are de- 
fined. 

Menus are the other important entity in 
the Smalltalk-80 user interface. They exist 
in two varieties: fixed and pop-up. A fixed 
menu is a subview of a displayed view; the 
user moves a cursor over the menu items 
with a mouse and selects an item by press- 
ing the leftmost mouse button. This action 
highlights the selection. Releasing the but- 
ton invokes the selected command. A pop- 
up menu appears directly under the cursor 
when the user holds down one of the other 
mouse buttons. As the cursor is moved 
around the menu, the item underneath the 
cursor is suitably highlighted. Upon releas- 
ing the button, the item is selected and the 
menu disappears. 

Since the screen space available to pre- 
sent a view may not be large enough to 
contain all the information that needs to be 
presented, Smalltalk-80 provides the scroll 
bar, a special type of menu that allows the 

8 Smalltalk-80 is a trademark of the Xerox Corpora- 
tion. 
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Figure 17. Smalltalk-80 screen and mouse. (Courtesy Xerox Corporation.) 


being viewed. For example, in Figure 18a, 
the gray bar indicates that about the last 
half is being viewed; in Figure 18b, the first 
half is being viewed; in Figure 18c, the 
entire document is being viewed. To jump 
to a particular place in the document, the 
user puts the cursor in the gray rectangle, 
holds down the leftmost button, and drags 
the gray rectangle up and down by moving 
the mouse. Moving the rectangle simulates 
changing the placement of the viewing 
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(a) (b) (c) 

Figure 18. Smalltalk-80 scroll bar. (Courtesy Xerox 
Corporation.) 

buffer on the document. Upon releasing the 
button, the view is changed to reflect this 
viewing buffer placement. To scroll down 
(up) the user places the cursor on the left 
(right) of the gray rectangle, and the cursor 
automatically changes to a down (up) ar- 
row. Upon pressing the leftmost button for 
downward scrolling, the line of text closest 
to the line of text at the top of the view is 
moved to the cursor position. Upon press- 
ing the leftmost button for upward scroll- 
ing, the line of text closest to the cursor is 
moved to the top of the view. Other menus 
include confirmers, which allow a user to 
select one of two displayed choices, and 
prompters, which allow the user to “fill in 
the blank” in response to a question or 
message. 

To edit text in a system-specified view, 
the user makes extensive use of the mouse 
and the supplied menus. Pressing and re- 
leasing (“clicking”) the leftmost button on 
the mouse causes a caret to appear in the 
intercharacter gap closest to the cursor. 
This essentially selects a zero-length string. 
If the user continues to hold down the 
leftmost button, all the characters between 
the initial caret and the current position of 
the cursor are highlighted in reverse video. 
Releasing this button causes the high- 
lighted text to become the active selection. 
Two clicks on the leftmost button while the 
cursor remains stationary select the word 
On which the cursor lies, unless the cursor 
is at the beginning or end of the document, 
in which case the entire document is se- 
lected, or unless the cursor lies just after 
(before) a left (right) parenthesis, square 
bracket, angle bracket, single quote, or dou- 
ble quote, in which case the text between 
the delimiter pair is selected. 

'•n ■ j 
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Replacement fits naturally with the con- 
cept of selection. Inserting characters is 
simply a form of replacement. The user 
moves the cursor to the gap in which the 
string is to be inserted, does a single click 
to get the caret, anti begins typing, which 
causes characters to be inserted at this spot: 
the user is essentially replacing the zero- 
length string with the string being typed 
(see Figure 19). If a larger area is selected, 
the typed-in text replaces the selection (the 
first typed character causes the deletion of 
the selected area). 

Copying and moving are done analo- 
gously. The proper selection is made and 
either the copy or the cut button is selected 
from the pop-up view menu controlled with 
the middle mouse button. Both commands 
store the selected text in a paste buffer; 
copy leaves the selected text unscathed, 
while cut deletes it. Now the user is free to 
perform any action; the copy and cut are 
finished. When desired, the user simply se- 
lects a destination point, selects the paste 
command in the menu, and the proper in- 
sertion is made. If the user has just selected 
and replaced text, again, another command 
in the pop-up menu, will hunt for the next 
occurrence of the pattern that was selected 
and replace it with the text used for the 
replacement. If the user selects text and 
then issues the again command, the system 
will simply search forward for the selected 
pattern, and if found, select it so the user 
may cut it or replace it (see Figure 20). An 
undo command allows the reversal of the 
previously issued command. 

Most Smalltalk-80 commands are issued 
by either clicking a mouse button, or by the 
dual motion of first pressing a mouse button 
to select a menu item and then releasing 
the button to invoke the associated com- 
mand. When a command is not available 
this way, the user simply finds some empty 
view space, types in the appropriate com- 
mand, selects it, and then issues the dolt 
command. Later on, one may come back, 
edit that command in the normal way, and 
reissue it. Thus commands are edited as 
easily as text; indeed, commands are simply 
text. The printlt command is identical to 
dolt, with the exception that any output 
result is placed immediately after the com- 
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this is some existing text. Jhe caret indicates the 
location at which insertion takes place. 


This is some existing text. Simply type to insert 
characters x The caret indicates the location at which 
insertion takes place. 


Figure 19. Insertion in Smalltalk-80. (Courtesy Xerox Corporation.) 


mand text to which printlt was applied and 
this result is automatically selected. 

The environment supports a wide range 
of tools for the development of Smalltalk- 
80 programs. While most are beyond the 
scope of this paper, we mention browsers 
as an interesting method for traversing 
hierarchies. Objects in the Smalltalk-80 
language are built hierarchically. For in- 
stance, number is a class name that is in 
the browser class category numeric ob- 
jects. Similarly, the operation of absolute 
value is a message selector that is in the 
browser numeric-number message cate- 
gory arithmetic. To find information about 
these quickly, the user simply selects nu- 
meric objects in the class category subview 
in the browser, which brings up the appro- 
priate classes in the class name subview. 
The user next selects Number in the class 
name view, which brings up the appropriate 
method categories in the message category 
subview. The user than selects arithmetic, 
which brings up all appropriate messages in 
the message selector subview. Choosing one 
of these message selectors, for example abs, 
causes the Smalltalk-80 procedure for that 
method to be brought up in the editing view 


below (see Figure 21a). The user is free to 
edit this procedure using the editing facili- 
ties described earlier. Pointing to an item 
in a subview further up the hierarchy re- 
places the subviews below, and allows the 
user to browse through new definitions. For 
instance, as in Figure 21b, selecting trun- 
cation and round off in the class category 
subview causes a new message category 
subview to be generated and the message 
selector subview to be changed. Subse- 
quently, selecting truncated causes a new 
procedure to appear in the editing subview. 

The browser is important not only for its 
convenient techniques for tree traversal, 
but for its notion of letting a user browse 
through an entire collection of information, 
examining and editing it at will. A browser- 
like interface would be attractive in other 
environments as well, such as that of ex- 
amining a file system hierarchy or travers- 
ing a hierarchically structured menu sys- 
tem. Indeed, the access to local and remote 
files is provided in the Smalltalk-80 system 
through appropriate browsers in which file 
name patterns are specified and file names 
are selected for reading, retrieving, or edit- 
ing. 
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2. ISSUES 

2.1 The State of Editor Design 

While much is written about “the desirable 
human interface,” most of it (unsupported) 
personal opinion, very little experimen- 
tation in determining the optimal editor 
interface has been done. Typically, editor 
design is based not on concrete experimen- 
tal results, but on market pressure to design 
systems that conform to today’s often worn 
technology (such as 24 X 80-character ter- 
minals, and half-duplex communication to 
time-sharing systems). Rather than con- 
centrating on desired functionality and ease 
| ; of use, the editor designer is then forced to 
devote large amounts of time to molding 
the user interface to the constraints of par- 
ticular classes of limited input and output 
devices, producing a far from optimal inter- 
face. 

In our editing model, the lexical phase of 
the command language processor, which 
composes tokens from lexemes, is followed 
by a syntactic phase, which parses sen- 
tences of these atomic tokens. In principle, 
33 we want each token’s appearance and 
meaning to be unambiguous in all contexts, 
and its user image to be unique, easily 
Ht remembered, and unobtrusive. For typed 
‘i;, command languages, this is not the case: 
ii the user must correctly spell or abbreviate 
& the needed tokens, usually from memory, 
and the system must be in the appropriate 
„ “command" mode so that command tokens 
are accepted as such, and not as literal text. 
In control-key interfaces, tokens are com- 
posed by overloading the alphanumeric 
keyboard with control or prefix keys to 
j; form cryptic combinations. 

If tokens are atomic entities unto them- 
selves, why do we need a lexical component 
' to compose them at all? In fact, the token 
composition phase is one of the most 
treacherous parts of a user interface, and is, 
for all practical purposes, unnecessary with 
modem technologies. The pure function 
key interface, for example, assigns a token 
to a particular key; composition of tokens 
is not necessary. The flaw in this technique 
is that the number of function keys grows 
linearly with the number of tokens; a many- 
function editor would need a massive, un- 
tenable keyboard. One type of interface 
that begins to satisfy the criteria of atomic 
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tokens without incurring the expense of 
linear growth of input devices is the menu 
interface, more explicitly, one that uses 
pop-up menus in temporary viewports and 
selection devices like the mouse (see Small- 
talk-80 in Section 1). In general, menus 
supply composed tokens in a form the user 
easily recognizes. No memorization of to- 
kens is needed, since the necessary images 
appear as needed; the user simply points to 
the appropriate image and selects it. The 
menu presents to the user only those tokens 
that are viable at any particular time, un- 
like the function keyboard, which is obliged 
to have all tokens at all times to avoid 
overloading. The menus are unobtrusive; 
when not in use they disappear and only 
pop up when called. Another interface sat- 
isfying this criterion is the Star interface. 
Star eliminates the problem of overloading 
commands by having a small set of general- 
purpose function keys such as open, move, 
and find that provide the majority of tokens 
needed, a rich set of icons that serve as 
tokens as well, property sheets and option 
sheets that provide consistent access to to- 
kens as well as a consistent method for 
composing new tokens in these sheets, and 
finally, window-specific menus containing 
selectable command tokens. 

Design techniques pose another problem. 
Many editors in production today have 
been designed by programmers for pro- 
grammers, and have been foisted upon the 
general public with little apparent regard 
for its needs. Many others appear to have 
been designed by nonprogrammers for non- 
programmers, and show little evidence of 
proper software engineering and language 
design principles, such as consistent user 
instruction sets and consistent syntax. 
Clearly few editors have been designed by 
rigorous examination of reasonable choices 
in interface and functionality, and even 
fewer are backed by a well-explained con- 
ceptual model. Rather, editing design has 
been ad hoc, with the editor often becoming 
a potpourri of contradictory techniques and 
functions, copying and inheriting poor de- 
sign from previous systems (“we can always 
change it or write another one”). It is time 
that editor designers, like programming lan- 
guage designers, commit their conceptual 
models and user interfaces to paper before 
implementation. This requires extensive 
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search of the literature, analysis of altei- 
natives, and experimental validation of 
ideas, all traditional actions in science and 
engineering but disappointingly rare in this 
field. 

2.2 The Modeless Environment 

There has been much recent interest in so- 
called “modeless environments” [TeslSI]. 

In fact, the term “modeless” is a bit of a 
misnomer since no system can be truly 
without modes. What is intended is that 
modes be minimized, and that designers 
move away from implementing special-pur- 
pose context-sensitive slates and com- 
mands of Ihe type that SOS has. The pri- 
mary problem with modes is that they lock 
the user into a specialized and typically 
highly restricted functionality while in the 
mode, preempting the use of the normal set 
of functions and thereby severely limiting 
flexibility. With current techniques for 
command specification there is often a sec- 
ond problem, that of assigning different 
meanings to user actions as a function of 
the mode, as is the case in overloaded key- 
boards. 

The goal of the modeless editor is to 
allow the user to have the flexibility to 
travel and to select operands without hav- 
ing to commit to a particular function and 
the particular options that it allows. In 
particular, the postfix form of command 
specification in which the operands precede 
the command is more conducive to mini- 
mizing modes than the prefix form. The 
latter is typically used to put the user in a 
temporary mode and then prompt for the 
operand (s): for example, move puts the user 
in a mode that requires the user to specify 
the source and then the destination. This 
style of guided dialogue, while useful for 
novices, is often frustrating and annoyingly 
time consuming for experts. Furthermore, 
it enforces sequential specification of mul- 
tiple operands, without providing the abil- 
ity to edit them. Worst, of course, is that 
the user is locked into the dialogue, and 
cannot leave to browse or to collect infor- 
mation with which to complete the com- 
mand (see Tesler’s painfully amusing ex- 
ample in Tesl81). 

With postfix syntax, the user spends most 
time browsing and selecting without com- 


mitting to a particular function. When i! 
function is specified, it is executed indivi 
bly and the user is back immediately in I 
familiar and universal operand select i 
“mode,” free to browse, to create oil 
window/viewport combinations, and to 
lect and revise selection of operands befi 
specifying another operation. It would 
possible to allow the user to escape frou 
temporary operation mode in prefix ini. 
action, but a great deal more status savi 
would be required. 

In the case in which certain commui 
require more than a single operand follow 
by an operator, there are several alien 
lives in a postfix system: (1) split a ce 
pound operation into smaller primitive > 
erations that fit the postfix constraint 
in two single-operand cut and paste co 
mands to replace move); (2) allow multi 
selection of operands, although this 
comes difficult if the order of specificat 
is important; (3) allow the use of famii 
editing functions for specifying paramet 
and for setting attributes by letting the u 
fill out a form and then execute a comm: 
based on this form; and (4) tempora 
switch to infix specification. For an exam 
of the last alternative, a move comm, 
that takes both a source and a destinat 
would be specified in the normal way 
selecting first the source and then mi 
Then, the system would enter tempo: 
move mode, ask the user to select the ■ 
tination, execute the move command, 
return to the familiar operand selec. 
mode. 

The Star system uses the third alte 
tive above, providing option sheet to 
that do not preempt the user (as show 
Section 1). To issue the find command 
example, the user presses the find key, 
the option sheet, fills in the appropi 
parameters, and then issues a comn. 
that actually does the search. Using 
form metaphor, the user has the abilil 
select information from other parts 
screen as input to the form, and of coi 
has the ability to edit the form as wel 
fact, the form can be used to Simula 
dialogue. As the user fills in particula 
formation or toggles particular attribi 
the system can provide further fields i 
filled in. If the user goes back and edit; 
of the fields, all of the field values 
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depended upon one particular field value 
may be undone. (See the example of Star 
query-replace in Section 1.) Not only does 
the form metaphor simulate interactive dia- 
logues, but it obviates the sequentiality and 
noneditability problems of conventional 
dialogues. Why then is filling in a form not 
considered a “dangerous mode”? In fact, 
form filling is a mode of sorts, yet familiar 
functions can be used to edit it. Most im- 
portantly, the user can leave the context of 
the form, issue other commands, and return 
without loss of context. 


2.3 Instant Editor/Formatters versus Batch 
Formatters 

The classical separation between form and 
content enforced by batch formatting is 
becoming increasingly less desirable. Space 
and layout constraints often force altera- 
tion of content to make text fit. Further- 
more, text can be interpreted in a surpris- 
ingly different way when typeset than when 
it is printed as draft copy on a line printer. 
This, of course, is the reason it is typeset at 
all. That computer scientists, reporters, 
copy editors, and even professional printers 
have tolerated the system of marked up 
alterations and specifications on typewrit- 
ten copy or bad facsimiles of a final typeset 
galley is a result of economics and not an 
implicit confirmation of that system. The 
typesetting conventions that make it easier 
to understand text in printed form make it 
correspondingly easier to understand the 
on-line form. For all these purposes and 
especially for complex formatting tasks (ta- 
bles, equations), interactive formatting is 
clearly highly desirable. 

Yet, there is a strong camp advocating 
continued use of batch formatting systems, 
with possible soft-copy review, to allow 
maximum flexibility and power, especially 
in terms of multiple interpretations of 
markup tags (e.g., those that indicate dif- 
ferent document styles and output devices). 
Allen et al. [Alle 81] advocate the use of 
soft-copy output that is later more precisely 
formatted by a document compiler. They 
contend that the interactive user does not 
need a finely formatted document, but sim- 
ply one that approximates the final printed 
result. The interactive system does not 
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need to perform expert formatting; this is 
left to a batch document compiler. The 
underlying notion is that no matter how 
accurate interactive formatting systems can 
become, those (batch) methods that spend 
more time will produce higher quality out- 
put. 

Still, interactive editor/formatters seem 
to have compelling advantages over editors 
that have a separate, editable representa- 
tion for formal ling effects, and certainly 
over the separate interactive editing/batch- 
compiling method. The ability to experi- 
ment with different formats is clearly in- 
valuable to both author and transcriber, 
providing that there are no serious restric- 
tions resulting from this facility. Having to 
“program” formatting effects is a mental 
burden and requires sophisticated, compli- 
cated code all too often; debugging a se- 
quence of formatting codes is difficult un- 
less a formatted copy of the same document 
exists for comparison. 

On the other hand, the problem with 
some interaci ive editor/formatters, often 
called “what-you-see-is-what-you-get” edi- 
tors is that, as Brian Kernighan has re- 
marked, "what you see is all you've got.” 
That is, it is just as uninformative and 
unhelpful to give a user a view of a beauti- 
fully formatted document with no clues as 
to how or why the formatting was effected 
as it is to give the user a file laden with 
complicated formatting codes without the 
rules for what these formatting codes will 
do. However, the stripping of formatting 
information is not necessary to interac- 
tively produce a finely formatted docu- 
ment. Referring back to our editor model 
in Part I, Section 1, we can interpret the 
finished document page as simply one of 
many useful views, but not the only one to 
which the user should be restricted. In fact, 
the property sheet of Star and the margin 
tags of ETUDE are simply specially tai- 
lored views of the document data structure. 
In particular, structure editing can be nicely 
done on representations that stress the 
structure and suppress formatting infor- 
mation — one can rearrange sections in an 
outline much more easily if only the section 
headings and the first line of each section 
are displayed, as in NLS. Also, as Jan 
Walker has pointed out [WALK81a], it is 
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often important to know why a particular 
formatting effect is apparent; it is useful to 
be able to interrogate and alter the higher 
level document object specification that 
caused the effect. 

The principle of multiple views, one that 
has been sorely underutilized in the 
hundreds of editors that have been created, 
shows that a completely reasonable solu- 
tion to satisfy both camps is to provide 
whatever views each desires. The batch 
community might get a view that allows 
them to edit textual descriptions of format- 
ting, equations, anti tables, while the inter- 
active community might be given a view 
that allows interactive specification of ta- 
bles and equations, as well as of the tradi- 
tional simple (and local) formatting effects. 
Except for the additional implementation 
time, there is no reason to restrict the user 
to editing a single interpretation or view; 
the multiple-viewing principle needs to be 
adopted in systems of the future. 

I 

2.4 Structure/Syntax-Directed Editors 
versus '‘Normal” Editors 

With the increase in the number of struc- 
ture editors, several designers have ex- 
plained the rationale behind what seems at 
first to be a restrictive concept. 

Advocates of structure editors claim that 
the specification of target data as well-con- 
nected, well-defined units enhances the 
user's powers of creativity and composition. 
Engelbart, describing a key idea in NLS, 
writes: 

With the view that the symbols one works with are 
supposed to represent a mapping of one’s associated 
concepts, and further that one's concepts exist in a 
"network” of relationships as opposed to the essen- 
tially linear form of actual printed records, it was 
decided that the concept-manipulation aids deriva- 
ble from real-time computer support could be ap- 
preciably enhanced by structuring conventions thut 
would make explicit (for both the user and the 
computer) the various types of network relation- 
ships among concepts .... We have found that in 
both offline and online computer aids, the concep- 
i tion, stipulation, and execution of significant manip- 
ulations are made much easier by the structuring 
conventions .... We have found it to be fairly 
universal, that after an initial period of negative 
reaction in reading explicitly structured material, 
one comes to prefer it to material printed in the 


normal form. [EngeIIS, pp. 3US-399. Keprinn . 
permission AFIPS Press] 

Burkhart and Nievergelt [Bukk80] i 
cur with the view that while the structu 
seems to be a restriction on the user 
pecially the novice), who may not wan 
be forced to keep track of the data hit 
chically, the structuring would ultima 
be performed anyway, “into chapters 
paragraphs, procedures and modules, : 
pictures and patterns, as the semantii 
the data may suggest.” 

Using his Cornell Program Synthes 
as an example, Teitelbaum claims the v 
of the syntax-directed editor to be the 
that a program being developed is alv 
structurally sound, even if not comp 
The use of structural templates elirnin 
mundane program development tasks 
dentation and prettyprinting are autom 
typographical errors are possible onl 
user-typed phrases, not in system-sup) 
templates, and such errors can be e. 
caught at run time. The templates 
keystrokes, as one typed command 
generate a long template. Place holdei 
the templates act as prompts, guiding 
user along the proper path. The user n 
needB to get mired in low-level synt. 
detail— the constructs are always cor, 
tualized as abstract units, not as streai 
tokens. 

On the other side, Woods [Woo 
claims that a good “standard” editor c» 
95 percent of the program editing tl, 
syntax-directed editor can, at much sm 
development and computation costs 
claims that syntax-directed editing 
strains the user interface, complicatini 
erations that are normally easy in a si 
aid editor. This is true of some opera, 
in the available interfaces today, but i 
an intrinsic restriction on future interl 
He further claims that the syntax-dir, 
approach promotes a multitude of edi 
This is only partially true; editor gener 
such as the Cornell Synthesizer Genei 
the GANDALF/ALOE project [No'i 
Feil80, Medi81], and sds show that eci 
for very different targets can have the : 
basic editing operations. In fact, the i 
larity of the structure editor introduce 
ability to produce formal descriptioi 
generate special-purpose editors. This 
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allels the trend to create parser generators 
and compiler generators from formal de- 
scriptions. Woods’s claim that the represen- 
tation and editing of a program as a parse 
tree makes an editor harder to implement 
is certainly true; yet, again, the syntax-di- 
rected editor eliminates the need for a par- 
ser completely. 

Notkin points out that syntax-directed 
editing may change the way that program- 
ming is taught and described [Notk79]. For 
instance, “nitty-gritty'’ details such as 
placement of statement delimiters like 
semicolons could be eliminated entirely, 
since the templates will carry whatever in- 
formation is necessary to create a structur- 
ally correct program. 

Morris and Schwartz [Morr81, p. 29], 
among others, contend that syntax-directed 
editors are “profligate consumers of com- 
puter resources .... Parsing consumes pro- 
cessing power, the parse tree devours stor- 
age, and there is no solution but to supply 
plenty of each.” With high-performance 
personal work stations that possess virtual 
memory, however, this is no longer a very 
important consideration. 

We believe that given adequate machine 
resources and a well-engineered human in- 
terface (perhaps a two-dimensional syntax 
with interesting icons), there are many rea- * 
sons to prefer a syntax-directed approach 
to editing. However, we know of no formal 
determination of trade-offs between “nor- * 
mal” editors and structure/syntax-directed 
editors. We hope that controlled experi- 
ments in this area will result in the neces- 
sary data for an objective, informative eval- * 
uation of the utility of structure/syntax- 
directed editors. 


3. CONCLUSION 

3.1 Desiderata for Today’s Editor 

As in programming languages and most 
computer systems, the “desirability” of the 
syntax and semantics associated with an 
interactive editor is largely a matter of in- 
dividual taste. Often, however, constraints 
imposed by old techniques and methodol- 
ogies and acceptance of outmoded technol- 
ogies (e.g., 300-baud “glass teletypes”) force 
inferior modes of communication. Without 
being unduly constrained by the limitations 
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of old-fashioned technology, we suggest our 
design criteria for an ideal interactive editor 
within the limits ol today’s modern tech- 
nology. Such an ideal editor should have 

• A well-defined, consistent conceptual 
model, lather than a seemingly haphaz- 
ard organization. The user must be fa- 
miliar and comfortable with the 
“philosophy” behind the system. 

• Documentation, both on-line in a help 
facility and off-line in manuals, which 
explains the conceptual model as well as 
the details of the user interface and the 
functions of the system. 

• A clear and concise user interface that is 
easy to learn and to use and that provides 
consistency across different targets such 
as text, pictures, and voice. Indeed, a good 
test of an efficient and pleasing interface 
is that authors will use the system to 
compose and revise manuscripts them- 
selves. We believe that the author should 
not need to involve others (experts or 
“wizards” to advise, secretaries to make 
changes) in any phases of document cre- 
ation or editing. 

• An “infinite" undo/redo capability, ena- 
bling an author to experiment without 
concern of loss or damage to a document. 

• Fast response time. No noticeable delay 
should exist for all but the most complex 
commands. 

• Powerful facilities, with few restrictions 
and exceptions, to make possible every- 
thing that one can do to hard copy with 
red pencil, ruler, scissors, and tape. 

• Facilities that take advantage of com- 
puter capabilities to compensate for hu- 
man limitations. Examples of existing fa- 
cilities include global substitution of one 
pattern for another throughout a docu- 
ment, replication of a standard phrase or 
paragraph, and automatic renumbering 
of sections or references after (or while) 
a file is edited. Some of these facilities 
may duplicate human processes; others 
may be functions that are available only 
with the power of a computer. 

• User access to shared information and 
files under controlled conditions (useful 
for a pool of researchers or documentors 
working in the same area, or for common 
access to dynamically updated manage- 
ment information). 
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• The ability to mix targets, such as text, 
graphics, programs, and forms, with ease. 

• The ability to have multiple contexts on 
the same display surface, allowing the 
user to browse through and use a large 
assortment of familiar utilities and docu- 
ments in an editing session. The editor 
should not force the user into a smaller, 
less powerful environment in which nor- 
mally provided system functions are 
preempted. In fact, the editor should be 
part of a larger, integrated environment, 
allowing the user, in the middle of an 
editing session, to obtain information by 
looking through the file system, to use a 
desk calculator utility, or to retrieve an 
electronic mail message or a piece of data 
from a database system, with transparent 
return to the editing context. 

• The ability to edit a close facsimile of the 
final composition, layout, and typography 
of the document without significant im- 
pact on computer response time. 

3.2 Standardization 

Several ANSI (American National Stand- 
ards Institute) and ISO (International Or- 
ganization for Standardization) committees 
(ANSI X3J6 and X3V1, ISO/TC 97/SC 5/ 
EGCLPT) are considering standardization 
of generic markup languages, text-process- 
ing languages, text formatting, text editing, 
and text structures. We consider the agree- 
ment upon a standard editor, unfortu- 
nately, as unrealistic at this time. What is 
needed first is a standard reference model 
for editing (e.g., one based on the frame- 
work in Part I, Section 1). The acceptance 
of at least an interim reference model on 
which to base further research and devel- 
opment of editors will be helpful for a pro- 
ductive interchange of ideas in the editing 
field. 

Another step toward standardization 
would be the definition of a set of opera- 
tions, called a virtual editing protocol 
(VEP) [Maxe81, Wild82] that acts upon 
any medium, such as text, graphics, or 
voice. The VEP would not define how op- 
erations are performed on the medium, but 
simply what generic operations can be done 
on all media. The virtual editor for each 
medium accepts the medium-independent 


VEP and translates it to medium-di 
dent operations. 

3.3 The On-Line Community 

Just over ten years ago, in our first su 
of the field, we concluded 

On-line composition and editing of program- 
pled with interactive debugging, has hecon 
established, cost-effective use of computers 
larly, minor text editing, such as the correct i 
typographical errors in memoranda, is cost-ell t 
since only teletypewriter consoles and minim, 
vice from the CPU are required. In contras 
imaginative use of computers for on-line con 
tion and extensive manipulation of free- form t 
still in the early stages of experimentat ion an. 
conversion. This is due partially to the high t 
CRT terminals that provide the human facto 
sential to general-purpose editing, partially i 
high cost of system resources and implement 
time for the sophisticated programs require! 
partially to the long time required to wean 
from traditional off-line hurd-copy processes. 

Hardware prices are coming down steadily 
ever, and as more users switch to on-line thi. 
creating, and manipulating, the use of conq 
will become increasingly accepted (and judget 
effective), hopefully to the same extent that n 
ical and data processing applications are al 
considered to be a legitimate use of the com 
[vAND71b, p. 113] 

In the ensuing decade, this hope fo 
large-scale introduction of text proce 
was realized, as a result of rapidly dec 
ing hardware prices, the acceptanc 
word-processing systems in business 
introduction of personal computet 
hundreds of thousands of homes an. 
fices, and the rapid growth of softwai 
interactive editing. Regrettably, much 
processing today is still done by tram 
tion from hard copy rather than by am 
composing and editing on line. This i? 
in part to generally poor interfaces (lit 
windows on alphanumeric screens and 
scription-oriented software), and in p« 
cultural resistance: typing, unfortunate 
not a universal skill and is still too 
considered an inappropriate activit; 
executives and other high-level de< 
makers. 

For the remainder of the decade 
indeed the century we see an ever-in< 
ing infiltration of editors. In one foi 
another they will become a fundam 
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tool of modern communication in all walks 
of life. They will be the key user interface 
to the work stations that will be used in the 
office, the classroom, the home, and any 
other place in which information is entered, 
edited, and communicated. They will in- 
creasingly be used for do-it-yourself, high- 
quality document production with sophis- 
ticated typesetting effects, as well as for on- 
line browsing, studying, composing, and 
communicating. 

As terminals and work stations become 
widely available and personal (i.e, become 
part of one’s office or study furniture that, 
like a clock radio, are rarely, if ever, turned 
off) increasingly more of one’s daily activi- 
ties will be accomplished via the computer, 
increasingly less via traditional paper and 
mechanical communication. There, is, in 
fact, a kind of “critical mass” phenomenon, 
in which a knowledge worker switches from 
hard copy to soft copy for most purposes, 
given the full-time availability of powerful 
local Services and a high-performance in- 
formation- and resource-sharing network. 
At that point, the Bush-Engelbart-Nelson 
visions of on-line communities will become 
commonplace realities and editors will be 
the key interface to all manner of document 
preparation and communication. We expect 
these editors to be suitable J^oth for stream 
ftpd strpcture, editing, and for targets as 
diverse,, as j, text, pictures, and voice. The 
more intelligence the editor has of both the 
fqrrn and, content of the manuscripts, the 
more powerful its capabilities will be. 

Just as advances in technology in the 
past decide have, provoked a marked 
change in editors, so will advances in inter- 
computer communication, speech synthesis 
and understanding, and, character and 
handwijti^g, reoognitiop, again change, the 
.way ip ;wl]iiph, editors are implemented., 

, Imagine, the following scenario. Families, 
businesses, and individuals will receive a 
symbolic computer address much as one 
receives a, telephone number. A user any- 
where, ini, the world with access to this ad- 
dress will be able to access the files at that 
network address as if they were on that 
user’s; own machine (subject to any confi- 
dentiality and, security restrictions im- 
posed). Interdocument links will be made 
easily by including this user address as the 


fust search criterion in the link address. 
Multiperson collaborations will become 
economically and technically feasible, and 
will make distributed knowledge work an 
attractive alternative to physical travel. 
Tymshare’s AUGMENT and Nelson’s 
Xanadu 7 system are ongoing projects to 
bring these concepts and many other ad- 
venturous document organization ideas to 
the general public. Nelson provides both an 
interesting history of the development of 
hypertext systems and a description of the 
Xanadu technical and organizational plans 
in Nels81. 

Each user will have a personal work sta- 
tion with a high-resolution (several- 
hundred-points-pei -linear-inch) bit-map 
display packaged in a flat, notebook-style 
package easily moved about a desk or car- 
ried in a briefcase [LRG76, Kay77, 
GRID82], Interaction may be done in many 
ways. A wireless mouse or a touch-sensitive 
screen will allow for cursor movement. The 
cursor may be used not only for selection 
of entities from a menu, but also for drawing 
proofreader’s symbols on a document or for 
entering text into the document. A symbol 
recognition program will understand the 
drawn symbols and perform the appropri- 
ate operation. If a symbol is inscrutable or 
ambiguous, the editor may notify the user 
using voice output. The user will have the 
choice of redrawing the symbol, or alter- 
nately, vocally inputting the commands (as 
well as, later, even natural-language text). 
While currently experimental and unport- 
able, the use of eye- tracking schemes 
[Bolt80, Bolt81] may allow the editor to 
determine at what (large) area the user is 
looking, enabling it to correctly understand 
commands such as “delete this paragraph.” 

Before the turn of the century, the edit- 
ing systems are likely to have taken the 
place of pen, paper, and typewriter — and 
not only for manuscript composition, For 
example, banks will have editors with pre- 
printed forms” that the user fills out using 
a keyboard or even natural handwriting. 
Documents will be interactive, compiled on 
demand especially for the requester. They 
will ,jje further personalized with on-line 


1 Xanadu is a registered trademark. , 
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annotation. Most important, schoolchildren 
will learn to both read and write with the 
editor and a nationwide library of on-line 
books. 

In fact, much of the technology for the 
near-term editor of the 1980s is in place. 
Among the hardware are bit-mapped per- 
sonal work stations, pointing devices, pre- 
cision laser printers, and digital photo- 
typesetters; among the software are multi- 
window text and graphics editors, interac- 
tive formatters/typesetters, ieonographic 
communications, and modeless environ- 
ments. The key issue of the 1980s is the 
willingness of users and manufacturers to 
discard existing techniques for even better- 
researched, better-understood, and better- 
developed metaphors of user interaction. 

In the broadest sense, most actions that 
people perform are editing operations of 
one form or another. In moving a car from 
here to there, making a shopping list, or 
playing chess, a person modifies or edits 
the state of some entity. In computing, most 
of the actions that people perform are ed- 
iting operations as well. It is inevitable that 
the interactive editor will soon enter a new 
generation, a generation in which it forms 
the primary interface to the computer. 

POSTSCRIPT 

The majority of this document was edited 
using the bb editor running on a VAX 11/ 
780 under Berkeley UNIX 4.1. Some parts 
of the document were occasionally edited 
using the Apollo editor, BBN’s PEN editor, 
and Brown’s CMS Editor. Besides these, 
the authors at one time or another have 
used ed, ex, vi, EMACS, SOS, the Cornell 
Program Synthesizer, FRESS, NLS, 
TECO, XEDIT, WordStar, Bravo, and 
Star. 

Formatting was initially done using the 
TROFF package under UNIX. A revised 
version was translated to 'Ij.jX by the use of 
keystroke macros in bb and through hand 
translation for some parts. No interactive 
formatting was available; the authors had 
to rely on hard-copy printouts from a Var- 
ian electrostatic printer-plotter (approxi- 
mately 5 pages/minute) to see the format- 
ting that the T^X codes had produced. The 
text consists of approximately 100, single- 


spaced, 12-inch high pages. With aroun 
drafts of the paper over more than 
years, we have regrettably used just u 
one mile of paper to produce a final il 
excluding the reams of paper used in d 
eating review copies. 

Communication of machine-read 
files and electronic mail was done tint 
the uucp inter-UNIX telephone net 
and through the Arpanet. 
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